einiges zu avanti (linux) -> das gute startskript

So Mai 23 03:20:02 CEST 2004

On Sat, 22 May 2004 11:40:25 +0200, Thomas Berger wrote:

guten abend (die zweite), herr berger

naja. ist ja eigentlich ganz einfach. wenn man sich durch das gewirr der unterschiedlichen avanti-files 
durchgekämpft hat. (hat hier irgendjemand gesagt, daß allegro&co leicht sei?)

eine datei ist für mich nach_wie_vor unklar:
/etc/avanti2/avanti2.conf
es gibt doch gar kein !verzeichnis! mit dem namen /etc/avanti2 ????
(s.a. vorherige mail)

kl>Hm. Normalerweise haben Pakete kein eigenes etc-Verzeichnis.
kl>Ich selber habe fuer mich daher eingefuehrt, in /etc/avanti.conf
kl>die Einstellungen zu machen. Das Verwaltungsskript aus
kl>/etc/init.d kopiert das dann an die unuebliche Stelle, wo avanti
kl>es erwartet. Wenn avanti chrooted ablaeuft, werden dabei auch
kl>gleichzeitig die Pfade umgeschrieben.

ja. eigentlich sonnenklar.
die conf oder cnf-files gehören nach /etc und evtl in dort vorhandene unterverzeichnisse (z.b. apache1 hat 
/etc/httpd; währenddessen apache2 ein /etc/apache2 hat; aber das gehört nicht hierher ;-)

kl>denke, wenn obiges geklärt ist, wird sich der dschungel um "starting
kl>avanti2" lichten.

ja, er hat sich ganz fix sogar gelichtet. der käfig wurde ausgeschaltet, und das startskript läuft ganz 
prima. (der käfig kommt später ran ;-)

es kann z.b. NICHT mehr passieren, daß avanti mehrmals als gleichberechtigtes programm läuft.
die antworten des startskriptes: start stop status u.a. sind sehr sauber.
(danke)

eine kleine macke gibt es noch, und das hat etwas mit suse's YAST zu tun. wird yast mit dem runlevel-editor 
aufgerufen, dann wird automatisch avanti runtergefahren. (bei mir unter 8.2 so!). mit webmin gibt es keine 
probleme! start/stop usw ist dort alles ok! sehr ok!

(kleine) frage(n):
startproc -e -l /var/log/avanti.out -t5 -u domainadmin -g www  .....
                ~~~~~~~~~~~~~~~~~ 
welchen sinn hat eigentlich diese logdatei? sie ist sicherlich NICHT ein ersatz für die avanti.log, die in 
avanti.conf definierg wird.

kl>| ich habe den eindruck, daß mit dem startskript eine künstliche welt
kl>aufgebaut wird. diese soll DEN DA
kl>| draussen ver(w)irren! ist die verwirrung tatsächlich nötig?
kl>
kl>Das mit der kuenstlichen Welt sehen Sie richtig. Die hat aber nicht
kl>unbedingt den Zweck zu verwirren, sondern sie soll ausreichend sein,
kl>damit ihre Einwohner lebensfaehig sind: Ein in einer chroot-Umgebung
kl>ablaufender Prozess sieht nur diese kuenstliche Welt und hat absolut
kl>keine Chance mehr, auf die "reale Welt" jenseits des Kaefigs
kl>zuzugreifen.

ja, sie setzen sogar ash ein. 
aber, ist denn die welt auf einem normalen linux-server nicht auch sicher? 
apache hilft dabei. ich habe document_root, ich habe data, auf die per avanti zugegriffen wird. auf die 
einzelnen rechte usw (chmod/chown) muss man natürlich aufpassen.
WAS kann da schiefgehen?

vielen dank für ihre (sehr) ausführlichen erklärungen!

kl>Es werden ja - optional!, ueber /etc/sysconfig/avanti2 konfiguriert -
kl>zwei Sicherheitsmechanismen angeboten, naemlich vor allem das Ablaufen
kl>unter einer User-ID ohne besondere Privilegien und zweitens das in-den-
kl>Kaefig-setzen. Letzteres ist dann fast zwingend, wenn der Prozess als
kl>root ablaufen muss, ansonsten eher verzichtbar (wegen der zusaetzlichen
kl>Verwirrung in den Pfaden, gegen die man nichts machen kann) manche
kl>Admins haben da aber etwas falsch verstanden und wollen es chrooted.
kl>Im Gegensatz zu anderen U**Xen erlaubt Linux tatsaechlich, beide
kl>Mechanismen simultan einzusetzen.
kl>
kl>Wenn Sie in /etc/sysconfig/avanti2
kl>AVANTI_RUN_CHROOTED="no"
kl>setzen, sind Sie die zusaetzliche Komplikation mit dem chroot-Kaefig
kl>los. Dann laeuft avanti dort, wo Sie es installiert haben, also etwa
kl>in (in init.d durch AVANTI_ROOT eingestellten) /opt/avanti
kl>(das ist bei mir ein symlink auf /opt/avanti-2.2 oder was gerade die
kl>aktuell installierte Version ist).
kl>Die zentrale Konfigurationsdatei /etc/avanti.conf wird dann auch stets
kl>nach /opt/avanti/etc/avanti.conf kopiert.
kl>
kl>Mittels startproc kann das init-Skript User und Gruppe beim Start von
kl>/opt/avanti/bin/avanti angeben, das ist eigentlich angenehmer als
kl>das Setzen des suid-Bits auf der Datei.

na, das ist ja ein weiterer pluspunkt: es kann auf sui(zi)d verzichtet werden.

kl>Die Vor- und Nachteile einmal gegenuebergestellt (manche Minusse
kl>koennten auch Plusse sein und umgekehrt, das ist eine Stilfrage):
kl>suid-Bit:
kl>~ + Egal wer startet, egal wie gestartet wird, avanti laeuft
kl>~   immer unter der eingestellten Benutzerkennung.
kl>~ - Nach jeder Aktualisierung der Binaries muessen die Flags
kl>~   und Owner neu gesetzt werden

ja, dazu bastelt man sich eins kript. die infos/bestandteile dazu hatte ich ja vor einigen tagen 
beschrieben. sie hatten korrekturen dazu notiert.

kl>~ - Ein Skript in /etc/rc3.d braucht man stets, damit avanti
kl>~   beim Boot automatisch gestartet wird, am besten jedoch (nur Linux)
kl>~   ein elaborierters in /etc/init.d, damit auch der Runlevel-Editor
kl>~   damit etwas anfangen kann

ist interessant: yast (oder wer?) hat automatisch in /etc/rc.d/rc3.d eine datei(link): 
@S13avanti2 reingeschieben .....

kl>Wie sich das Ganze nun mit dem PHP-Interface avadmin zusammenbringen
kl>laesst, ist mir nicht klar. Sicher ist zumindest, dass es chrooted
kl>nicht geht (man braucht killproc(8) um avanti sauber abzuschiessen,
kl>das geht nur privilegiert) und dass ein Stoppen oder Reloaden nur
kl>geht, wenn die Benutzerkennungen uebereinstimmen. Dafuer muss avanti
kl>entweder unter der Webserver-Kennung ablaufen oder aber - aber das
kl>ist dann von Server zu Server verschieden - man muss den Server so
kl>aufsetzen (etwa mit suExec unter Apache), dass die php-Admin-Skripte
kl>unter der Benutzerkennung von avanti ausgefuehrt werden.
kl>Herumpopeln in einer /etc/avanti.conf verbietet sich in beiden
kl>Situationen, d.h. hier muesste man auf eine in den Avanti-Verzeichnissen
kl>liegende Originalversion der avanti.conf zurueckfallen.

ja, die php.avanti's sind wohl immer noch nicht brauchbar.
denke dass hier die probleme (u.a.) auch liegen:
im pidfile. (in status wird /var/run/avanti.pid verlangt!). man sollte vielleicht sicherheitshabler das 
pidfile in conf.php ebenfalls definieren.

dann wird in der status.php dort beim starten nicht mit "startproc -e -l /var/log/avanti.out -t5 -u 
domainadmin -g www  ....." gearbeitet. 
kann man nicht in der status.php mit so etwas ähnlichem arbeiten wie s.o. -u und -g ???

kl>
kl>Ich denke, man wird auch langfristig zwei sehr verschiedene Szenarios
kl>beruecksichtigen muessen:
kl>* Ein avanti-optimierter Server, dort ist avanti stark in das
kl>~  System integriert (ueber ausgefeilte init-Skripten, chroot, eigene
kl>~  Mounts etc.), der "normale" Administrator ist fuer Betrieb und
kl>~  Konfiguration verantwortlich. Ein webbasierenden
kl>~  Verwaltungsmechanismus ist eher ueberfluessig und a priori ein
kl>~  Sicherheitsrisiko.
naja, der sicherheitsrisiken haben wir aber viele. man mehme nur die tools, die man sich aussuchen kann: 
ssh, webmin, dfü-shells (z.b. zoc); telnet kommt nicht in die tüte; was macht da avanti-php?

kl>bzw.
kl>* Ein avanti-User-Server: Hier wird avanti irgendwann irgendwie durch
kl>~  den Administrator lieblos abgeworfen, fuer start/stop und
kl>~  Konfiguration ist ein User zustaendig, dem man am liebsten auch
kl>~  einen Shell-Account verwehrt, d.h. es *muss* einen Webbasierenden
kl>~  Mechanismus fuer alle Administrationstaetigkeiten geben.

ja.

viele grüße
ihr
klaus lehmann

ps. danke noch mal für die sehr ausführlichen beiträge. einige waren zwar verwirrend, sie führten mich fast 
ins /dev/null , aber die letzten brachten einen zu /root ;-)

-- 
Klaus Lehmann
eMail: lehmann_klaus at t-online.de
*** allegroC-Dienstleistungen & Internetkataloge
*** Admin fuer Netware/Windows/Linux/Samba
*** Our best ideas are born at home (New Freedom Data Center 1995)
    one of those new ideas see at http://allegronet.de/ruck-film