einiges zu avanti (linux) -> das gute startskript [und so einiges anderes]
Klaus Lehmann
lehmann_klaus at t-online.de
So Mai 23 16:32:30 CEST 2004
On Sun, 23 May 2004 10:55:22 +0200, Thomas Berger wrote:
guten morgen herr berger
ich glaube, wir kommen so langsam ans ende....
und hoffe, daß einiges für die unix(linux)-lastigen mitleser interessant war ;-)
(dieses denke ich, weil, wie ich schon mal aufseuzend bemerkte, die doku zum thema unix/linux... naja....
ist)
kl>vielen Dank fuers Debuggen meines Startskripts!
danke auch. habe viel gelernt.
kl>| ich greife mal das raus:
kl>| test /etc/avanti2/avanti2.conf -nt $AVANTI_PID && echo reload
kl>| ~~~~~~~~~~~~
kl>| also, DAS hatten wir nicht ausgemacht ;-) wo kommt diese conf. her?
kl>
kl>garnicht. es sollte die normale avanti.conf sein. An dieser Stelle wird
kl>verglichen, ob die Datei $AVANTI_CONF (also bei mir /etc/avanti.conf )
kl>neuer ist als die pid-Datei von Avanti: Wenn ja, behauptet das Skript,
kl>dass ein Reload angebracht waere.
kl>
kl>Die Zeile sollte also lauten:
kl>test $AVANTI_CONF -nt $AVANTI_PID && echo reload
ja, so wird ein (turn)schuh draus. das ist mir logischer....
kl>Wenn avanti nicht als root laeuft, muss man etwas aufpassen, was die
kl>Rechte angeht: Hier muss man vorher in /var/run eine leere avanti.pid
~~~~~~~~~~~~~~~ moment. wer macht das? das sind doch alles selbstablaufende mechanismen. init.d und
konsorten. ich will da nix per hand einstellen/erzeugen müssen! es nervt mich schon total, seit einiger zeit
zu wissen besser zu beachten: wehe, wenn du mit yast in den runlevel-edi gehst, dann gehe zum schluss
gefälligst gucken, was avanti macht! das ist sicherlich noch herauszubekommen, was da bei yast
verantwortlich ist, was da avanti killt. das aber später. nicht alles auf einmal ;-)
wenn ich mich nicht irre, wird avanti.pid doch gelöscht, wenn avanti ordnungsgemäß mit avanti aus init.d
gestoppt wird. soll man dem stopper sagen, erzeuge eine leere avanti.pid? nee, ick weeess nich....
thema: avanti.log-killer
kl>| fehlt eine datei?
kl>huebsch ist /etc/logrotate.d/avanti2
ja, das ist ein weiteres gutes thema. irgendjemand sagte mir, die idee sei nicht gut. wenn logrotate die
log-datei killt, um sie zu tarren oder so, dann kann avanti diese datei nicht mit inhalten füllen, weil sie
nicht da ist. korrekt?
andererseits: in /etc/logrotate.conf steht:
# create new (empty) log files after rotating old ones
create
das müsste klappen....
und außerdem haben sie da unten postrotate und endscript zu stehen.
kl>/var/log/avanti/avanti.log {
ich packs bei mir lieber in /var/log/avanti.log ;-)
kl>~ daily
kl>~ dateext
kl>~ missingok
kl>~ compress
kl>~ copytruncate
kl>~ notifempty
kl>~ maxage 60
kl>~ rotate 99
kl>~ postrotate
kl>~ /etc/init.d/avanti2 reload
kl>~ endscript
kl>}
upps, jetzt kommen ja weitere kleine/große leckerlies!
thema: checken ob avanti noch läuft
kl>oder /etc/cron.d/avanti2:
kl>
kl># check existence of avanti every 5 minutes
kl>1-56/5 * * * * root ~avanti/bin/av-dog
kl>
kl>mit dem Skript ~avanti/bin/av-dog:
kl>
kl>#!/bin/sh
kl>
kl>function av_start() {
kl>~ echo "Have to restart avanti!";
kl>~ /etc/init.d/avanti2 restart;
kl>~ /etc/init.d/avanti2 status;
kl>~ return
kl>~ }
kl>/sbin/checkproc -c ~avanti/jail /bin/avanti || av_start;
kl># that's it
das ist ja ganz fabelhaft. sowas in der art hätte ich gerne mal selber (später!) gebaut ,-)
1000dank.
kleine frage:
kl>/sbin/checkproc -c ~avanti/jail /bin/avanti || av_start;
kl># that's it
den parameter -c kann ich nicht mir erklären. man checkproc nennt mir diesen nicht.
das soll sein: Checkproc - Checks for a process by full path name
was macht checkproc da?
in ZWEI orten? (symbollink? korrekt?) avanti/jail
UND /bin/avanti
dann wird av_start ausgeführt?!....
ist /bin/avanti ihr käfig? denke: ja..... und avanti/jail?
na, ick weess' nich..... ;-)
thema:yast
kl>| eine kleine macke gibt es noch, und das hat etwas mit suse's YAST zu
kl>tun. wird yast mit dem runlevel-editor
kl>| aufgerufen, dann wird automatisch avanti runtergefahren. (bei mir
kl>unter 8.2 so!). mit webmin gibt es keine
kl>| probleme! start/stop usw ist dort alles ok! sehr ok!
kl>
kl>Naja: Einerseits erkennt der runlevel-Editor, dass es etwas
kl>zu erkennen gibt:
kl>
kl>### BEGIN INIT INFO
kl># Provides: avanti2
kl># Required-Start: $syslog $remote_fs
kl># X-UnitedLinux-Should-Start: $time ypbind
kl># Required-Stop: $syslog $remote_fs
kl># X-UnitedLinux-Should-Stop: $time ypbind
kl># Default-Start: 3 5
kl># Default-Stop: 0 1 2 6
kl># Short-Description: avanti server for allegro databases
kl># Description: avanti server for access to databases under allegro-C
kl># (TU Braunschweig, http://www.allegro-c.de), listening on 4949 TCP
kl>### END INIT INFO
kl>
kl>andererseits sind in /etc/rc3.d und /etc/rc5.d die entsprechenden
kl>Links noch nicht eingerichtet (das macht schliesslich der runlevel-
kl>Editor). Beim Beenden (oder muss man dafuer einmal im runlevel-
kl>Editor den Dienst noch einmal aktivieren?)
ich kann leider die mechanismen nicht finden, die yast-runlevel-edi veranlassen, was zu tun.
-z.b. killt avanti, wenn man in den runlevel-edi reingeht (ohne unten links auf beenden zu gehen!)
-z.b. wer richtet die symbollinks in /etc/rc.d/rc3.d und .../rc5.d ein?
der symbollink wurde automatisch erzeugt in /rc3.d , aber nicht in rc5.d (obwohl ja im header entspechendes
notiert ist. nungu. für "unsere" zwecke benötigen wir kein init5 /(x-irgendwas) oder?
m.w. muss man den dienst nicht aktivieren. es reicht, wenn die zustände notiert sind. aber: kontrolle iss
besser ;-)
(CISS wird wieder ausrasten ;-) )
thema: der käfig von chroot zu avantis
kl>| aber, ist denn die welt auf einem normalen linux-server nicht auch
kl>sicher?
kl>| apache hilft dabei. ich habe document_root, ich habe data, auf die per
kl>avanti zugegriffen wird. auf die
kl>| einzelnen rechte usw (chmod/chown) muss man natürlich aufpassen.
kl>| WAS kann da schiefgehen?
kl>
kl>So genau kenne ich mich da nicht aus. Typische Exploits laufen wohl
kl>so ab, dass durch irgendwelche Eingabedaten der Prozess "kontrolliert"
kl>zum Absturz gebracht wird und dabei irgendwelche eigentlich nicht
kl>ueberschreibbaren Dateien ueberschreibt (Angeblich auch, wenn er
kl>nicht als root laeuft, aber als root gestartet wurde). Das ist
kl>dann der erste Schritt, um von ferne die Kontrolle ueber das
kl>System zu bekommen (vgl. die von Ihnen zitierten code-Red-Angriffe:
kl>Hier wird unter Windows etwas aehnliches gemacht, naemlich versucht,
kl>eine gefaelschte cmd.exe irgendwo unterzubringen). In einem chroot-
kl>Kaefig gibt es aber keine gefaehrlichen Orte mehr, weil das
kl>Dateisystem nur simuliert ist. Fuer ftp-Server z.B. ist das
kl>ziemlich gaengig.
naja. es ist aber auch sehr intellektuell, diese lösung. ;-)
meine basis in den überlegungen zur sicherheit ist die:
ich(!) muß mich darauf verlassen, daß apache weiterentwickelt wird. daß sicherheitslöcher erkannt und
annonciert werden.
ok: hier ein kleines problem . bei www.apache.org gibts es längst ein apache1.xx als neu. suse (muss da
leider immer drauf schauen:suse) hat dieses noch nicht in sein update-system eingebaut. derzeit aktuell
1.36.26. den daifi werd ich tun und mir die pakete holen. es gibt sicherlich kein rpm-paket. nee, da muss
man leider auf suse-vorkonfigurierte pakete warten.
abgesehen, daß es apache2 längst gibt, aber keine mit_installierte(=mod_pphp oder so) php4-unterstützung
meines wissens! habe mal parallel apache2 (unter suse) installiert. minimalste module sind installt. die
struktur für die conf, ist was die module angeht, sehr verändert. dann muss man sich für ein modell
entscheiden. prefork wird empfohlen. naja, das ist das los, wenn man von einer distribution abhängig ist. in
meinem fall: suse8.2. weiss nicht, wann mein server_provider mir 9.0 anbietet. es wird bestimmt ein nacktes
images sein. das heisst dann: den ganzen käs' neu aufsetzen.... da sitzt man wochen dran. geht aber nicht,
es ist ein "produktionsserver". und in einem guten jahr hört die unterstützung für suse8.2 auf. (das kommt
einem bekannt vor?!?; allerdings ist milckyweich da großzügiger, es hat erst vor kurzem die unterstützung
für windowsnt4 gekappt! nt4 ist seit 1995(?) draussen....
zum php nochmal. die mods existieren, aber nicht im angebot von suse's apache2. und mod_php (r)einbauen, ist
nich einfach. das mod_zip hab' ich ja shcon geschafft, einzubauen ,-)
thema: runlevel-edi
kl>| kl>~ - Ein Skript in /etc/rc3.d braucht man stets, damit avanti
kl>| kl>~ beim Boot automatisch gestartet wird, am besten jedoch (nur Linux)
kl>| kl>~ ein elaborierters in /etc/init.d, damit auch der Runlevel-Editor
kl>| kl>~ damit etwas anfangen kann
kl>|
kl>| ist interessant: yast (oder wer?) hat automatisch in /etc/rc.d/rc3.d
kl>eine datei(link):
kl>| @S13avanti2 reingeschieben .....
kl>
kl>der Runlevel-Editor, nachdem Sie Ihn aufgerufen hatten.
ja, aber nicht in rc5.d ! (s.o.)
kl>| denke dass hier die probleme (u.a.) auch liegen:
kl>| im pidfile. (in status wird /var/run/avanti.pid verlangt!). man sollte
kl>vielleicht sicherheitshabler das
kl>| pidfile in conf.php ebenfalls definieren.
kl>
kl>/var/run/avanti.pid ist fest verdrahtet. Existiert standardmaessig
kl>aber nur dann, wenn avanti als root laeuft (s.o.)
das erklärt das problem mit den avanti-php-tools...
so, für den sonntag (nur diesen?) reicht es. wir ermüden die mitleser ;-)
naja, die offenen fragen können ruhig noch beantwortet werden ;-)
denke, daß hier alles wesentliche besprochen wurde. jeder, der sich fit fühlt, kann sich aus dem
beschriebenen (s)eine install-doku zurechtbasteln.
viele grüße
ihr
k.lehmann
--
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
Mehr Informationen über die Mailingliste Allegro