Remote Update

Check ob neuer Snapshot vorhanden:

remote-update -c

Update durchführen:

remote-update 

Falls die Remote-Update-Einstellungen in der Datei /etc/config/freifunk fehlen, was bei einem Update von einem Snapshot älter als 30.06.2009 meist der Fall ist, muss die Mirror-URL angehängt werden. Hier im Beispiel das Update auf einem WRT, geholt vom Leipziger Mirror

remote-update -u http://firmware.leipzig.freifunk.net/kamikaze/brcm-2.4/openwrt-brcm-2.4-squashfs.trx 

Weitere Hilfe:

remote-update -h

und http://wiki.freifunk.net/Kamikaze/RemoteUpdate

Dienste stoppen und dauerhaft deaktivieren

Einen Dienst stoppen und deaktivieren so dass er nach einem Neustart oder durch Watchdog nicht wieder gestartet. Wurde im Zusammenhang mit dem stellenweise nicht funktionierenden Splash und der Bandbreitenbeschränkung gefragt.

/etc/inid.d/DienstName disable
/etc/init.d/DienstName stop

Update allgemein

Problem: Update per Web-Interface schlägt fehl.
Lösung: Update per Konsole.

WRT54Gx:

cd /tmp
wget http://firmware.leipzig.freifunk.net/kamikaze/brcm-2.4/openwrt-brcm-2.4-...
sysupgrade openwrt-brcm-2.4-squashfs.trx

DIR-300:

cd /tmp
wget http://firmware.leipzig.freifunk.net/kamikaze/atheros/openwrt-atheros-co...
sysupgrade openwrt-atheros-combined.img

Es bestand das Problem dass das Update per Web-Interface mit einem älteren Snapshot immer fehl schlug, das Image wurde hochgeladen, beim verifizieren des Images wurden die WRTs allerdings neu gebootet.

Problem: Update einer Fonera auf der ein alter Snapshot ohne RemoteUpgrade installiert ist.
Lösung: Update von Hand.

cd /tmp
wget http://firmware.leipzig.freifunk.net/kamikaze/atheros/openwrt-atheros-vm...
wget http://firmware.leipzig.freifunk.net/kamikaze/atheros/openwrt-atheros-ro...
mtd -e vmlinux.bin.l7 write openwrt-atheros-vmlinux.lzma vmlinux.bin.l7
mtd -r -e rootfs write openwrt-atheros-root.squashfs rootfs

SSH-Key für 192.168.1.1 aus known_hosts löschen

Problem: Man hat mehrere FF-Nodes  per direktem LAN-Anschluss zu administrieren, SSH meckert richtigerweise über einen falschen Key (WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!) beim verbinden mit einem anderen Node per LAN (default ist ja überall 192.168.1.1)

Lösung: ssh-keygen mit dem Schalter -R löscht den vermeintlich falschen Key aus der Datei .ssh/known_hosts

ssh-keygen -R 192.168.1.1

SSH Public Key Authentication

Problem: Bei jedem SSH-Login auf einen Node muss man das Passwort angeben, das kann bei vielem rumspielen oder debuggen wirklich nervig sein

Lösung: SSH-Key-Auth

falls noch kein DSA-SSH-Key erstellt wurde:

ssh-keygen -t dsa

Key manuell auf den Node übertragen, da auf den Routern kein standard sshd sondern dropbear läuft funktioniert ssh-copy-id -i nicht. Es wird noch ein letztes mal das Passwort zur Übertragung benötigt.

cat ~/.ssh/id_dsa.pub | ssh root@192.168.1.1 'umask 077; cat >>/etc/dropbear/authorized_keys'