5.3beta7 und einige ungereimtheiten

[CRAZyBUg]

Nach update von 5.2.1 auf 5.3beta7


is bei euch folgendes auch passiert und wenn ja, wie habt ihr es gelöst? Kann sein das diese Frage total nubi is aber ich find nirgends was dazu, hab auch schon die UPDATING durch:

1. Mein K5 wird als K6 / media Extensions gefunden (spinnt das bios oder freebsd?)

2. natd:
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Firewall rules loaded, starting divert daemons: natd
natd: Unable to create divert socket.: Protocol not supported
(clients kommen aber weiterhin ins inet)

3. Starting named.
usage: named [-4|-6] bla blubb alle commandline argumente
named: extra command line arguments

4. User basti ist weder in /etc/passwd noch in /etc/master.passwd trotzdem kann ich mich einloggen mit basti & passwort allerdings nur lokal und ned über ssh.
ein "rmuser basti" bringt zwar das alles erfolgreich gemacht wurde, er ist aber immernoch da.

5. ssh bringt mir keine passwort aufforderung wenn ich mich als basti oder ähnliches anmelde. bleibt einfach stehen, kein timeout nix...



jemand eine oder mehrere ideen? oder n tip wo mein denkfehler liegt?

 

[Tulkas]

2.)
/usr/src/UPDATING:
20041003:
The pfil API has gained an additional argument to pass an inpcb.
You should rebuild all pfil consuming modules: ipfw, ipfilter
and pf


3.)
/usr/src/UPDATING:
20041001:
If enabled, the default is now to run named in a chroot
"sandbox." For users with existing configurations in
/etc/namedb the migration should be simple. Upgrade your
world as usual, then after installworld but before
mergemaster do the following:

If named is running: /etc/rc.d/named stop
cd /etc
mv namedb namedb.bak
mkdir -p /var/named/etc/namedb
cp -Rp namedb.bak/* /var/named/etc/namedb/
mergemaster (with your usual options)
If using the generated localhost* files:
cd /var/named/etc/namedb
/bin/sh make-localhost
rm -f localhost-v6.rev localhost.rev
/etc/rc.d/syslogd restart
/etc/rc.d/named start

If you are using a custom configuration, or if you have
customised the named_* variables in /etc/rc.conf[.local]
then you may have to adjust the instructions accordingly.

 

[Maledictus]

1.)
das solltest du mal weiter untersuchen, und evtl. an current@ schreiben, da lesen leute mit, die sich damit gut auskennen.

4.) und 5.)
hast du mal pwd_mkdb(8) ausprobiert?

 

[Elessar]

Ausserdem wurde der Bind8 durch Bind9 ersetzt. Möglich also das die Bind8 Konfiguration nichtmehr mit Bind9 funktioniert (Bind trau ich alles zu).

 

[Cédric]

Ausserdem wurde der Bind8 durch Bind9 ersetzt. Möglich also das die Bind8 Konfiguration nichtmehr mit Bind9 funktioniert (Bind trau ich alles zu).

Muss in der Tat angepasst werden... also deine named.conf usw.
Das steht aber wie oben schon gesagt in der UPDATING

 

[CRAZyBUg]

Nach update von 5.2.1 auf 5.3beta7


is bei euch folgendes auch passiert und wenn ja, wie habt ihr es gelöst? Kann sein das diese Frage total nubi is aber ich find nirgends was dazu, hab auch schon die UPDATING durch:

1. Mein K5 wird als K6 / media Extensions gefunden (spinnt das bios oder freebsd?)

2. natd:
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Firewall rules loaded, starting divert daemons: natd
natd: Unable to create divert socket.: Protocol not supported
(clients kommen aber weiterhin ins inet)

3. Starting named.
usage: named [-4|-6] bla blubb alle commandline argumente
named: extra command line arguments

4. User basti ist weder in /etc/passwd noch in /etc/master.passwd trotzdem kann ich mich einloggen mit basti & passwort allerdings nur lokal und ned über ssh.
ein "rmuser basti" bringt zwar das alles erfolgreich gemacht wurde, er ist aber immernoch da.

5. ssh bringt mir keine passwort aufforderung wenn ich mich als basti oder ähnliches anmelde. bleibt einfach stehen, kein timeout nix...

jemand eine oder mehrere ideen? oder n tip wo mein denkfehler liegt?

so, es lag in der tat an den von euch geschriebenen Lösungen/Problemen.
4. gelöst mit pwd_mkdb

5. war damit auch gelöst weils basti nun wirklich nichtmehr gab.

3. Lag an einem von mir falsh durchgeführten mergemaster :/

2. Lag wie ich später gelesen habe, daran das neuerdings options IP_FORWARD
wieder in den Kernel muss um das forwarden zu unterstützen (war unter 5.2.1 nicht so)


thnx für die hilfe