[gelöst]/etc/init.d/boot.sysctl wird nicht korrekt gestartet

[Salzpeter]

Moin,

ich habe folgendes Problem:
Ich möchte, dass während des Bootvorgangs gewisse Kernelparameter gesetzt werden.
Laut verschiedenster Mailinglisten macht man dies am besten über Einträge in /etc/sysctl.conf und dem Hinzufügen von /etc/init.d/boot.sysctl zum Bootablauf.
Beides hab ich getan.
Nach dem Reboot jedoch sind die Parameter, die ich ändern möchte, immer noch mit ihren alten Werten versehen.

Führe ich nun ein sysctl -p als root aus, werden die Werte geändert und alles funktioniert so wie ich es möchte.
Ändere ich den Wert eines bereits vorhanden Parameters in der sysctl.conf, wird dieser Wert beim nächsten Neustart ebenfalls übernommen.

Hier ist meine sysctl.conf (die letzten drei Zeilen hab ich hinzugefügt):

# Disable response to broadcasts.
# You don't want yourself becoming a Smurf amplifier.
net.ipv4.icmp_echo_ignore_broadcasts = 1
# enable route verification on all interfaces
net.ipv4.conf.all.rp_filter = 1
# disable IPv6 completely
# net.ipv6.conf.all.disable_ipv6 = 1
# enable IPv6 forwarding
#net.ipv6.conf.all.forwarding = 1
# increase the number of possible inotify(7) watches
fs.inotify.max_user_watches = 65536
# avoid deleting secondary IPs on deleting the primary IP
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
# disable martian logging
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.eth0.log_martians = 0

Und hier ist noch ein Ausschnitt aus der /var/log/boot.msg der zeigt, dass boot.sysctl auch ausgeführt wird (siehe letzte Zeile):

<notice -- Sep 10 08:17:13.740636000> service boot.localfs done<notice -- Sep 10 08:17:13.741547000> service boot.cleanup start<notice -- Sep 10 08:17:13.741985000> service boot.cycle start<notice -- Sep 10 08:17:13.742375000> service boot.klog start<notice -- Sep 10 08:17:13.742788000> service boot.localnet start<notice -- Sep 10 08:17:13.743213000> service boot.proc start<notice -- Sep 10 08:17:13.743659000> service boot.swap start<notice -- Sep 10 08:17:13.744227000> service boot.sysctl start<notice -- Sep 10 08:17:13.794145000> service boot.proc done<notice -- Sep 10 08:17:13.794244000> service boot.udev_retry start<notice -- Sep 10 08:17:13.799725000> service boot.cycle doneSetting current sysctl status from /etc/sysctl.confdone

Wenn ich zum Beispiel in /etc/init.d/boot.local die Zeilen:
echo "0" > /proc/sys/net/ipv4/conf/all/log_martians
echo "0" > /proc/sys/net/ipv4/conf/eth0/log_martians

eintrage, werden die Werte beim Boot ebenfalls korrekt gesetzt.

Testweise habe ich aus dem boot.sysctl init-Skript die -q -e Parameter für den sysctl Aufruf entfernt (verhindern Konsolen Output des Programms) und im Boot Log erscheinen diese Einträge

Setting current sysctl status from /etc/sysctl.confnet.ipv4.icmp_echo_ignore_broadcasts= 1
net.ipv4.conf.all.rp_filter = 1
fs.inotify.max_user_watches = 65536
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.eth0.log_martians = 0

Also werden die Werte wie gewollt gesetzt, der konkrete Inhalt der jeweiligen Dateien bleibt jedoch weiterhin bei "1".

Im Novell Bugtracker habe ich keinen zutreffenden Bug gefunden. Ist der Fehler also auf meiner Seite oder ist das Problem bisher niemandem aufgefallen?

Edit: Ich benutze OpenSuse 11.3. Bei dem Rechner handelt es sich um eine mit Xen 4.0 erstellte DomU

 

[josef-wien]

Im Novell Bugtracker habe ich keinen zutreffenden Bug gefunden. Ist der Fehler also auf meiner Seite oder ist das Problem bisher niemandem aufgefallen?

Eine Suche in den Dateien von /etc/ hätte Dich zur Datei /etc/sysconfig/SuSEfirewall2 geführt.

Wenn ich zum Beispiel in /etc/init.d/boot.local die Zeilen ... eintrage, werden die Werte beim Boot ebenfalls korrekt gesetzt.

Das kann wohl nicht sein, denn /etc/init.d/boot.local wird auf jeden Fall vor /etc/init.d/SuSEfirewall2_setup ausgeführt, und dort werden die betreffenden Felder durch /sbin/SuSEfirewall2 auf "1" gesetzt.

Entweder beschäftigst Du Dich eingehend mit SuSEfirewall2, oder Du änderst FW_KERNEL_SECURITY auf "no" (zu den Konsequenzen kann ich nichts sagen), oder Du gehst einen pragmatischen Weg wie z. B. Aktivieren des Punkts 25. von /etc/sysconfig/SuSEfirewall2 und Einbau der echo-Befehle im letzten Block von /etc/sysconfig/scripts/SuSEfirewall2-custom.

 

[Salzpeter]

Entweder beschäftigst Du Dich eingehend mit SuSEfirewall2, oder Du änderst FW_KERNEL_SECURITY auf "no" (zu den Konsequenzen kann ich nichts sagen), oder Du gehst einen pragmatischen Weg wie z. B. Aktivieren des Punkts 25. von /etc/sysconfig/SuSEfirewall2 und Einbau der echo-Befehle im letzten Block von /etc/sysconfig/scripts/SuSEfirewall2-custom.

Danke für deine Antwort!

FW_KERNEL_SECRUITY auf "no" zu setzen scheint mir ein bisschen zu viel des Guten zu sein, wenn ich mir den dazugehörigen Kommentar angucke.

# Do you want to enable additional kernel TCP/IP security features?
# If set to yes, some obscure kernel options are set.
# (icmp_ignore_bogus_error_responses, icmp_echoreply_rate,
# icmp_destunreach_rate, icmp_paramprob_rate, icmp_timeexeed_rate,
# ip_local_port_range, log_martians, rp_filter, routing flush,
# bootp_relay, proxy_arp, secure_redirects, accept_source_route
# icmp_echo_ignore_broadcasts, ipfrag_time)

Einen Punkt 25 gibt es jedoch nicht in /etc/sysconfig/SuSEfirewall2 (bzw weiß ich nicht was damit gemeint sein soll). Ich werde mir erstmal SuSEfirewall2-custom näher anschauen

EDIT: Okay, jetzt weiß ich was mit Punkt 25 gemeint war...unter 11.3 sind die einzelnen Konfigurationsblöcke nicht mehr nummiert, in 11.2 hingegen waren sie es noch.

Jedenfalls geht es um den Punkt FW_CUSTOMRULES. Hier hab ich den entsprechenden Verweise auf "/etc/sysconfig/scripts/SuSEfirewall2-custom" eingetragen und, wie von josef-wien vorgeschlagen, in den letzten Block der Datei folgende Schleife hinzugefügt:

for IF in /proc/sys/net/ipv4/conf/*/log_martians
        do
                echo "0" > $IF
        done

Jetzt ist das syslog endlich wieder lesbar