Danke für die Liste. Ich werde die mal durcharbeiten. Schöner wäre natürlich, wenn Herr Bradler mal einen Liste der nötigen Pakete für CentOS 8 posten würde. libnsl und libxcrypt sind beide in beiden Varianten schon installiert.
PD-Admin und CentOS 8
-
-
Ich habe die bekannte Liste an Paketen verwendet, welche auch für CentOS 7 angegeben wird. Lediglich groff musste angepasst werden und die beiden genannten Libs zusätzlich installiert werden.
Nur weiß ich eben nicht, ob es nicht doch Unterschiede ziwschen dem B&K Image und Ihrem Image gibt. Ich hatte den Eindruck, dass bei Ihrem Image das epel Repository nicht installiert/aktiviert war da Sie schrieben dies gäbe es unter CentOS 8 nicht mehr.
-
Ich habe auch die Pakete aus der Liste für CentOS 7 installiert. Epel nutze ich normalweise nicht. Aber ich denke Hr. Bradler weiß am besten, welche Pakete benötigt werden, dann muss man das nicht versuchen mühsam herauszufinden.
-
Also ich habe jetzt mal einfach "alle" Pakete aus der Liste installiert. Aber die Dienste starten nicht.
Ich denke das Problem liegt an den daemontools die irgendwie nicht richtig laufen.
-
Welche Ausgabe liefert /command/svscanboot denn, wenn Sie es manuell auf der Konsole starten?
-
Der Befehl liefert keine Ausgabe. Er bleibt hängen, aber in /var/log/messages zeigt er folgendes an:
Feb 17 10:17:01 vserver10 systemd[1]: Started Session 2746 of user root.
Feb 17 10:17:02 vserver10 clamd[27956]: Pid file removed.
Feb 17 10:17:02 vserver10 clamd[27956]: --- Stopped at Mon Feb 17 10:17:02 2020
Feb 17 10:17:02 vserver10 clamd[27956]: Socket file removed.
Feb 17 10:17:02 vserver10 clamd[10631]: Received 0 file descriptor(s) from systemd.
Feb 17 10:17:02 vserver10 clamd[10631]: clamd daemon 0.102.2 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
Feb 17 10:17:02 vserver10 clamd[10631]: Running as user simscan (UID 1011, GID 1011)
Feb 17 10:17:02 vserver10 clamd[10631]: Log file size limited to 1048576 bytes.
Feb 17 10:17:02 vserver10 clamd[10631]: Reading databases from /usr/local/pd-admin2/share/clamav
Feb 17 10:17:02 vserver10 clamd[10631]: Not loading PUA signatures.
Feb 17 10:17:02 vserver10 clamd[10631]: Bytecode: Security mode set to "TrustSigned".
Feb 17 10:17:02 vserver10 dovecot-log[10642]: 1581931022.476418 doveconf: Warning: service auth { client_limit=5000 } is lower than required under max. load (6000)
Feb 17 10:17:02 vserver10 dovecot-log[10642]: 1581931022.491968 Warning: service auth { client_limit=5000 } is lower than required under max. load (6000)
Feb 17 10:17:02 vserver10 dovecot-log[10642]: 1581931022.492010 Warning: fd limit (ulimit -n) is lower than required under max. load (1024 < 5000), because of default_client_limit
Feb 17 10:17:02 vserver10 qmail-msa[10634]: 1581931022.688353 tcpserver: status: 0/12
Feb 17 10:17:02 vserver10 smtpd[10645]: 1581931022.721960 tcpserver: status: 0/450
Feb 17 10:17:02 vserver10 proftpd[10637]: 2020-02-17 10:17:02,938 vserver10 proftpd[10639] 85.25.110.52: ProFTPD 1.3.6b (maint) (built Mon Feb 10 2020 19:00:18 CET) standalone mode STARTUP
Feb 17 10:17:37 vserver10 clamd[10631]: Loaded 6742852 signatures.
Feb 17 10:17:42 vserver10 clamd[10631]: LOCAL: Unix socket file /tmp/clamd
Feb 17 10:17:42 vserver10 clamd[10631]: LOCAL: Setting connection queue length to 200
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: Global time limit set to 120000 milliseconds.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: Global size limit set to 104857600 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: File size limit set to 26214400 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: Recursion level limit set to 16.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: Files limit set to 10000.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxEmbeddedPE limit set to 10485760 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxHTMLNormalize limit set to 10485760 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxHTMLNoTags limit set to 2097152 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxScriptNormalize limit set to 5242880 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxZipTypeRcg limit set to 1048576 bytes.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxPartitions limit set to 50.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxIconsPE limit set to 100.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: MaxRecHWP3 limit set to 16.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: PCREMatchLimit limit set to 100000.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: PCRERecMatchLimit limit set to 2000.
Feb 17 10:17:42 vserver10 clamd[10631]: Limits: PCREMaxFileSize limit set to 26214400.
Feb 17 10:17:42 vserver10 clamd[10631]: Archive support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: AlertExceedsMax heuristic detection disabled.
Feb 17 10:17:42 vserver10 clamd[10631]: Heuristic alerts enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: Portable Executable support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: ELF support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: Mail files support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: OLE2 support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: PDF support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: SWF support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: HTML support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: XMLDOCS support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: HWP3 support enabled.
Feb 17 10:17:42 vserver10 clamd[10631]: Self checking every 600 seconds.
-
In den Log Zeilen ist kein Fehler enthalten. Dies hilft daher leider nicht weiter.
Ich habe nun auch CentOS 8 bei mir lokal mit VirtualBox installiert. Verwendet wurde das CentOS 8 Boot Image mit der "Minimal Installation". Dort habe ich dann noch folgende Pakete installiert
Bashyum -y install epel-release yum -y update yum -y install wget patch groff-base make gcc gcc-c++ glibc-devel libstdc++-devel zlib-devel zlib.i686 libgcc.i686 ncurses-libs.i686 glibc.i686 ImageMagick rrdtool net-tools iptables-services libnsl libnsl.i686 libxcrypt libxcrypt.i686 screen unzip psmisc nmap unzip
und anschließend die pd-admin Installation durchgeführt:
Die Installation führe ich mit "screen -L" aus, da ich so die komplette Bildschirmausgabe in einer Datei loggen und ggf. nach Fehlern durchsuchen kann. Aber auch hier kommt es bei mir zu keinerlei Problemen. Die Dienste starten ganz normal. Auch in den Logs sind keine Fehler zu finden.
Bash
Alles anzeigenpstree systemd─┬─NetworkManager───2*[{NetworkManager}] ├─agetty ├─atd ├─auditd─┬─sedispatch │ └─2*[{auditd}] ├─chronyd ├─crond ├─dbus-daemon───{dbus-daemon} ├─irqbalance───{irqbalance} ├─lsmd ├─polkitd───5*[{polkitd}] ├─rngd───2*[{rngd}] ├─rsyslogd───2*[{rsyslogd}] ├─smartd ├─sshd───sshd───sshd───bash───pstree ├─sssd─┬─sssd_be │ └─sssd_nss ├─svscanboot─┬─readproctitle │ └─svscan─┬─supervise───mysqld_safe───mysqld───39*[{mysqld}+ │ ├─supervise───clamd───{clamd} │ ├─supervise───proftpd │ ├─supervise───dovecot─┬─anvil │ │ ├─config │ │ └─log │ ├─supervise───spamd───2*[spamd child] │ ├─2*[supervise───tcpserver] │ ├─3*[supervise───splogger] │ ├─supervise───logger │ ├─supervise───qmail-send─┬─qmail-clean │ │ ├─qmail-lspawn │ │ ├─qmail-rspawn │ │ └─splogger │ └─supervise───httpd─┬─httpd │ └─25*[httpd───4*[{httpd}]] ├─systemd───(sd-pam) ├─systemd-journal ├─systemd-logind ├─systemd-udevd └─tuned───3*[{tuned}] nmap localhost Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-17 06:04 EST Nmap scan report for localhost (127.0.0.1) Host is up (0.0000040s latency). Other addresses for localhost (not scanned): ::1 Not shown: 992 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 80/tcp open http 110/tcp open pop3 143/tcp open imap 443/tcp open https 587/tcp open submission Nmap done: 1 IP address (1 host up) scanned in 1.64 seconds
-
Der Befehl liefert keine Ausgabe. Er bleibt hängen, aber in /var/log/messages zeigt er folgendes an:
Den Logfileeintraege nach laeuft svscanboot, und es wurden Serverdienste gestartet. Was ist die Ausgabe von pstree und "svstat /service/*"?
-
Hier die Ausgaben
pstree:
├─auditd───{auditd}
├─chronyd
├─crond
├─dbus-daemon───{dbus-daemon}
├─firewalld───{firewalld}
├─httpd─┬─httpd
│ └─25*[httpd───4*[{httpd}]]
├─irqbalance───{irqbalance}
├─login───bash
├─mysqld_safe───mysqld───28*[{mysqld}]
├─polkitd───7*[{polkitd}]
├─rngd───4*[{rngd}]
├─rsyslogd───2*[{rsyslogd}]
├─sshd─┬─sshd───sshd
│ ├─sshd───sshd───bash───pstree
│ └─sshd───sshd───bash───tail
├─sssd─┬─sssd_be
│ └─sssd_nss
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-resolve
├─systemd-udevd
└─tuned───3*[{tuned}]
svstat /service/*
/service/apache24: supervise not running
/service/clamd: supervise not running
/service/dovecot22: supervise not running
/service/mysqld: supervise not running
/service/proftpd: supervise not running
/service/qmail-msa: supervise not running
/service/qmail-send: supervise not running
/service/qmail-smtpd: supervise not running
/service/spamd: supervise not running
-
Hier die Ausgaben
Da haben Sie svscanboot aber nicht auf der Shell gestartet.
-
Doch so
[root@vserver10 /]# /command/svscanboot
ich habe es auch im Verzeichnis /command mit
[root@vserver10 command]# ./svscanboot
versucht.
-
Der Befehl liefert keine Ausgabe. Er bleibt hängen, aber in /var/log/messages zeigt er folgendes an:
Führt man svscanboot aus erhält man auch keine Ausgabe. Der Service wird in dem Moment aber ausgeführt:
Sie haben offenbar die Ausführung abgebrochen und dann pstree ausgeführt. Entsprechend ist der Prozess dann nicht mehr vorhanden. Anders sieht dies aus wenn man den Prozess im Hintergrund startet:
Bash
Alles anzeigen[root@localhost ~]# pstree systemd─┬─NetworkManager───2*[{NetworkManager}] ├─agetty ├─atd ├─auditd─┬─sedispatch │ └─2*[{auditd}] ├─chronyd ├─crond ├─dbus-daemon───{dbus-daemon} ├─firewalld───{firewalld} ├─irqbalance───{irqbalance} ├─lsmd ├─polkitd───5*[{polkitd}] ├─rngd───2*[{rngd}] ├─rsyslogd───2*[{rsyslogd}] ├─smartd ├─sshd───sshd───sshd───bash───pstree ├─sssd─┬─sssd_be │ └─sssd_nss ├─systemd───(sd-pam) ├─systemd-journal ├─systemd-logind ├─systemd-udevd └─tuned───3*[{tuned}] [root@localhost ~]# /command/svscanboot & [1] 2185 [root@localhost ~]# pstree systemd─┬─NetworkManager───2*[{NetworkManager}] ├─agetty ├─atd ├─auditd─┬─sedispatch │ └─2*[{auditd}] ├─chronyd ├─crond ├─dbus-daemon───{dbus-daemon} ├─firewalld───{firewalld} ├─irqbalance───{irqbalance} ├─lsmd ├─mysqld_safe───mysqld───38*[{mysqld}] ├─polkitd───5*[{polkitd}] ├─rngd───2*[{rngd}] ├─rsyslogd───2*[{rsyslogd}] ├─smartd ├─sshd───sshd───sshd───bash─┬─pstree │ └─svscanboot─┬─readproctitle │ └─svscan─┬─supervise───spamd───2*[spamd child] │ ├─supervise───clamd │ ├─2*[supervise───tcpserver] │ ├─3*[supervise───splogger] │ ├─supervise───proftpd │ ├─supervise───logger │ ├─supervise───mysqld_safe───mysqld───12*[{mysqld}] │ ├─supervise───qmail-send─┬─qmail-clean │ │ ├─qmail-lspawn │ │ ├─qmail-rspawn │ │ └─splogger │ ├─supervise───dovecot─┬─anvil │ │ ├─config │ │ └─log │ └─supervise───httpd─┬─httpd │ └─25*[httpd───4*[{httpd}]] ├─sssd─┬─sssd_be │ └─sssd_nss ├─systemd───(sd-pam) ├─systemd-journal ├─systemd-logind ├─systemd-udevd └─tuned───3*[{tuned}]
svscanboot wird üblicherweise bei CentOS 7 & 8 per systemd gestartet (siehe pstree im vorherigen Post). Dies ist bei Ihnen nicht der Fall. Stattdessen werden der httpd und mysql_safe direkt von systemd gestartet. Hier würde ich ja glatt vermuten, dass diese als reguläre Dienste (vor-)installiert sind und laufen. Dies stört natürlich dann auch die Dienste, welche von daemontools gestartet werden.
Hier die Ausgaben
pstree:
├─auditd───{auditd}
├─chronyd
├─crond
├─dbus-daemon───{dbus-daemon}
├─firewalld───{firewalld}
├─httpd─┬─httpd
│ └─25*[httpd───4*[{httpd}]]
├─irqbalance───{irqbalance}
├─login───bash
├─mysqld_safe───mysqld───28*[{mysqld}]
Was sagt bei Ihnen denn
Bei meinem lokalen Testsystem ist nach einem Neustart folgendes aufgetreten:
Bash
Alles anzeigen[root@localhost ~]# systemctl status daemontools ● daemontools.service - DJB daemontools Loaded: loaded (/usr/lib/systemd/system/daemontools.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2020-02-18 02:42:53 EST; 55s ago Process: 984 ExecStart=/command/svscanboot (code=exited, status=203/EXEC) Main PID: 984 (code=exited, status=203/EXEC) Feb 18 02:42:53 localhost.localdomain systemd[1]: daemontools.service: Service RestartSec=100ms expired, scheduling restart. Feb 18 02:42:53 localhost.localdomain systemd[1]: daemontools.service: Scheduled restart job, restart counter is at 5. Feb 18 02:42:53 localhost.localdomain systemd[1]: Stopped DJB daemontools. Feb 18 02:42:53 localhost.localdomain systemd[1]: daemontools.service: Start request repeated too quickly. Feb 18 02:42:53 localhost.localdomain systemd[1]: daemontools.service: Failed with result 'exit-code'. Feb 18 02:42:53 localhost.localdomain systemd[1]: Failed to start DJB daemontools.
Mit journalctl -xe findet sich folgender Eintrag:
CodeFeb 18 03:02:40 localhost.localdomain systemd[1751]: daemontools.service: Failed to execute command: Permission denied Feb 18 03:02:40 localhost.localdomain systemd[1751]: daemontools.service: Failed at step EXEC spawning /command/svscanboot: Permission denied
Ursache des Ganzen ist selinux. Dieses lässt den Start von daemontools nicht zu. Deaktiviert man selinux starten die Dienste regulär:
Code
Alles anzeigen[root@localhost ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config [root@localhost ~]# reboot [root@localhost ~]# systemctl status daemontools ● daemontools.service - DJB daemontools Loaded: loaded (/usr/lib/systemd/system/daemontools.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2020-02-18 03:07:58 EST; 3min 21s ago Main PID: 940 (svscanboot) Tasks: 203 (limit: 23977) Memory: 1.6G CGroup: /system.slice/daemontools.service ├─ 940 /bin/sh /command/svscanboot ├─ 951 svscan /service [...]
Ich vermute jetzt einmal, dass dies ebenfalls bei Ihnen die Ursache sein wird.
-
Hallo Sumeragi, vielen Dank für die ausführliche Erklärung. Es war nur das selinux was die Dienste nicht zugelassen hat. Jetzt läuft es.
Ich werde jetzt noch einmal alles neu installieren und nur die wirklich nötigen Pakete nach der Liste oben installieren und direkt selinux
deaktivieren, dann berichte ich noch einmal.
-
Hallo Sumeragi, ich habe jetzt noch einmal CentOS 8 neu minimal installiert, dann selinux deaktiviert und dann alle Pakete aus Deiner Liste installiert.
Danach dann pd-admin installiert und alles läuft perfekt. Vielen Dank noch einmal für Deine Mühe. Ich habe Deine Informationen zur Installation für die anderen mal in der Installations-FAQ hinterlegt.
-
Heute probiere ich mal centos81 minimal aus.
Irgendwie dauert das runterladen des pdadmin ewig. bis zu drei minuten für jedes paket:
Aktuelle Version der Server-Umgebung (SE) wird ermittelt
--2020-04-29 16:06:37-- http://download.pd-admin.de/SE-LATEST
Resolving download.pd-admin.de (download.pd-admin.de)... 2a02:e00:ffff:fff5:225:90ff:fe05:101, 130.255.184.84
Connecting to download.pd-admin.de (download.pd-admin.de)|2a02:e00:ffff:fff5:225:90ff:fe05:101|:80... failed: Connection timed out.
Connecting to download.pd-admin.de (download.pd-admin.de)|130.255.184.84|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6 [application/octet-stream]
Saving to: 'SE-LATEST'
SE-LATEST 100%[===================>] 6 --.-KB/s in 0s
2020-04-29 16:08:48 (677 KB/s) - 'SE-LATEST' saved [6/6]
-
Ich habe mit yum -y install fail2ban installiert und dabei wird auch exim mit drauf gespielt.
Das kann ich aber mit remove nicht so einfach runter nehmen.
Gibt es für centOS auch sowas wie den exim-Mailer-Patch auf Debian?
Habe im Forum bei der Suche danach irgendwie nichts gefunden.
-
-
Der Cronjob für ce_dhe_params.sh macht:
nice -n 19 /opt/pdadmin/bin/ci_dhe_params.sh
/usr/local/pd-admin2/share/mkdhparams: line 41: /usr/local/bin/certtool: No such file or directory
Mit welchem Paket muss bei centos das certtool installiert werden?
-
Das Skript /opt/pdadmin/bin/ci_dhe_params.sh ist ein Überbleibsel aus Courier-Zeiten. Die generierte Datei dhparams.pem wird nicht mehr verwendet.
Falls man aber unsicher ist reicht es in /usr/local/pd-admin2/share/mmkdhparams die Zeile
if test "gnutls" = "openssl"
in
if test "openssl" = "openssl"
zu ändern.
-
Das Thema war da schon angefangen, deshalb ist es wohl auch kein reines centOS Problem