Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
linux:slug [2009/11/15 17:03] – More explicit examples of commands to enter. alien | linux:slug [2010/04/24 18:33] – sendmail installation example alien |
---|
The firmware that ships with the NSLU2 does not have a telnet server. The only management interface is the web interface.\\ | The firmware that ships with the NSLU2 does not have a telnet server. The only management interface is the web interface.\\ |
The NSLU2 will start out of the box on IP address "''192.168.1.77''" so you should be able to quickly access it at [[http://192.168.1.77|http://192.168.1.77]]. If you do not use the subnet **''192.168.1.0/255.255.255.0''** in your network, then you will have to configure a computer with an IP address in that range and use a cross-cable or a ethernet switch in order to make your computer and the NSLU2 talk to each other. Alternatively you can configure an //IP alias// for your computer's network card: assign an address in the NSLU2's network range to that alias interface and then connect the NSLU2 to your LAN.\\ The default //username/password// combination of the web interface of the NSLU2 is "''admin/admin''". | The NSLU2 will start out of the box on IP address "''192.168.1.77''" so you should be able to quickly access it at [[http://192.168.1.77|http://192.168.1.77]]. If you do not use the subnet **''192.168.1.0/255.255.255.0''** in your network, then you will have to configure a computer with an IP address in that range and use a cross-cable or a ethernet switch in order to make your computer and the NSLU2 talk to each other. Alternatively you can configure an //IP alias// for your computer's network card: assign an address in the NSLU2's network range to that alias interface and then connect the NSLU2 to your LAN.\\ The default //username/password// combination of the web interface of the NSLU2 is "''admin/admin''". |
| |
| <note tip>If you are __re-flashing__ your //slug// (for instance if you try to recover from a bad flash, see below) then the device's IP address will not be ''192.168.1.77'' but the address it was using before the re-flash - i.e. the one you gave it.</note> |
| |
Once you flashed the NSLU2, you will have to enable the telnet server of the //uNSLUng// firmware before you can do anything else (do not attach any external storage yet!). The default //username/password// combination for the uNSLUng firmware is "''root/uNSLUng''".\\ To enable the telnet server, you will have to use the web-based management interface - [[http://192.168.1.77/Management/telnet.cgi|http://192.168.1.77/Management/telnet.cgi]]. | Once you flashed the NSLU2, you will have to enable the telnet server of the //uNSLUng// firmware before you can do anything else (do not attach any external storage yet!). The default //username/password// combination for the uNSLUng firmware is "''root/uNSLUng''".\\ To enable the telnet server, you will have to use the web-based management interface - [[http://192.168.1.77/Management/telnet.cgi|http://192.168.1.77/Management/telnet.cgi]]. |
<note warn>Do not turn off the NSLU2 while you are flashing it! Also do not try to use a wireless network connection for this.</note> | <note warn>Do not turn off the NSLU2 while you are flashing it! Also do not try to use a wireless network connection for this.</note> |
| |
| If you are re-flashing a bad flash (it happened to me: the flash got corrupted somehow and the //slug// would no longer properly boot), leave off the "--verify" because that will verify the flash content prior to re-flashing and report failure: <code> |
| $ upslug2 --device eth2 --verify --image Unslung-6.10-beta.bin |
| |
| NSLU2 00:14:bf:63:4b:23 Product ID: 1 Protocol ID: 0 |
| Firmware Version: R23V29 [0x2329] |
| |
| Upgrading LKG634B67 00:14:bf:63:4b:67 |
| . original flash contents * packet timed out |
| ! being erased - erased |
| u being upgraded U upgraded |
| v being verified V verified |
| |
| Display: |
| <status> <address completed>+<bytes transmitted but not completed> |
| Status: |
| * timeout occurred + sequence error detected |
| |
| 17fdbf+0005c0 ...VVVVVVVVvvUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU |
| 00:14:bf:63:4b:67: flash verification error (address 0x17FDC0, length 1472) [std::exception] |
| The verification step failed, the flash has not been written |
| correctly (or maybe there is a bug in upslug2). Try repeating |
| the verification step and, if that fails for the same reason, |
| try repeating the whole upgrade. |
| </code> |
| |
| Recovering from a //bad flash// is straight-forward: just re-flash. As long as you do not overwrite the //RedBoot// sector, you are doing nothing that can cause irreversible harm. |
| |
==== Unslinging to flash device ==== | ==== Unslinging to flash device ==== |
After flashing with new firmware, enable the telnet server, login as //root// and while logged on perform the "//unsling//": | After flashing with new firmware, enable the telnet server, login as //root// and while logged on perform the "//unsling//": |
| |
* Plugin a flash disk (512MB or larger) into the "''Disk 2''" port | * Plugin an unformatted flash disk (512MB or larger) into the "''Disk 2''" port |
* In the Web GUI, [[http://192.168.1.77/Management/disk_fs.htm|http://192.168.1.77/Management/disk_fs.htm]] check that the | * In the Web GUI, [[http://192.168.1.77/Management/disk_fs.htm|http://192.168.1.77/Management/disk_fs.htm]] check that the flash disk is detected, and let the NSLU2 format it. After formatting it must display as "''Formatted (EXT3)''"! |
flash disk is detected, and let the NSLU2 format it. After formatting it must display as "''Formatted (EXT3)''"! | |
* In the telnet session (stay logged in!) enter <code>unsling disk2</code>. You will have to enter a new password for root then. | * In the telnet session (stay logged in!) enter <code>unsling disk2</code>. You will have to enter a new password for root then. |
* Afer the //unslining// process completes, a comment is left in your telnet terminal that you have to reboot the machine: <code> | * Afer the //unslining// process completes, a comment is left in your telnet terminal that you have to reboot the machine: <code> |
| |
After //unslinging//, install the following packages as a minimum: | After //unslinging//, install the following packages as a minimum: |
* openssh, rsnapshot, cron, syslog-ng, util-linux, less, e2fsprogs, nfs-utils, man, screen, procps, sendmail, logrotate, nail, diffutils <code> | * openssh, rsnapshot, cron, syslog-ng, util-linux, less, e2fsprogs, nfs-utils, man, screen, procps, sendmail, logrotate, nail, diffutils, ntpclient <code> |
# ipkg update | # ipkg update |
# ipg list | # ipg list |
</code> | </code> |
| |
This will automatically install the dependencies as well: | Please follow carefully the post-installation instructions shown on-screen after installing some of these packages (such as syslog-ng, nfs-utils) or they will not work properly. Sendmail will for instance state: <code bash> |
| sendmail will run as a daemon now. Alternatively, execute: |
| echo 'smtp stream tcp nowait root /opt/sbin/sendmail -bs' >> /etc/inetd.conf |
| echo '0-59/15 * * * * root /opt/sbin/sendmail -q & > /dev/null 2>&1' >> /etc/crontab |
| </code> |
| |
| Installing these base packages will automatically install their dependencies as well: |
* for openssh : openssl, zlib | * for openssh : openssl, zlib |
* for rsnapshot : coreutils, perl, rsync, openssh | * for rsnapshot : coreutils, perl, rsync, openssh |
# chmod 0755 /mnt/thevault/.private/.snapshots/ | # chmod 0755 /mnt/thevault/.private/.snapshots/ |
# chmod 0755 /mnt/thevault/.snapshots/ | # chmod 0755 /mnt/thevault/.snapshots/ |
</code> In ''/etc/exports'', add the directory ''.private/.snapshots/'' as a read only NFS export: <code> | </code> In ''/opt/etc/exports'', add the directory ''.private/.snapshots/'' as a read only NFS export: <code> |
/mnt/thevault/.private/.snapshots/ 127.0.0.1(ro,no_root_squash) | /mnt/thevault/.private/.snapshots/ 127.0.0.1(ro,no_root_squash) |
</code> In ''/etc/fstab'', mount ''.private/.snapshots/'' read-only under ''.snapshots/'' <code> | </code> In ''/etc/fstab'', mount ''.private/.snapshots/'' read-only under ''.snapshots/'' <code> |
| |
* Add these lines to root's crontab (crontab -e) so that daily and weekly snapshots are being generated (you can add more as desired, and at other times of course): <code> | * Add these lines to root's crontab (crontab -e) so that daily and weekly snapshots are being generated (you can add more as desired, and at other times of course): <code> |
30 23 * * * /opt/bin/rsnapshot daily | 0 */4 * * * /usr/local/bin/rsnapshot hourly |
0 01 * * sun /opt/bin/rsnapshot weekly | 30 23 * * * /usr/local/bin/rsnapshot daily |
| 0 23 * * * /usr/local/bin/rsnapshot weekly |
| </code> As you may notice, these crontab entries schedule the jobs with larger intervals to run a bit before the jobs that trigger more regularly.(//daily// runs 30 minutes before //hourly//; and //weekly// in turn runs 30 minutes before //daily//). This is to prevent for instance the //weekly// rsnapshot job to run before the //daily// job (the same goes for combinations of other intervals). If you would schedule them the other way round, a problem may arise in case the larger interval job would start (re)moving backup directories before the shorter interval job has finished it's work. |
| |
| <note>It seems that my changes to ''/etc/fstab'' are being overwritten at boot. However, there is an alternative to mounting through fstab: If the file ''/unslung/rc.local'' exists, it will be executed. So, I copied ''/etc/rc.d/rc.local'' to that file (it did not exist): <code> |
| cp -a /etc/rc.d/rc.local /unslung/rc.local</code> removed the line <code> |
| if ( [ -r /unslung/rc.local ] && . /unslung/rc.local ) ; then return 0 ; fi |
| </code> and then added these lines at the bottom: <code> |
| mount -t ext3 -o defaults,usrquota /dev/sdb1 /mnt/thevault |
| mount -t nfs localhost:/mnt/thevault/.private/.snapshots /mnt/thevault/.snapshots |
| </code></note> |
| |
| ==== The rsnapshot log file ==== |
| |
| In ''/opt/etc/rsnapshot.conf'' I have uncommented the line <code> |
| logfile /opt/var/log/rsnapshot |
| </code> and disabled the syslogging. This creates a logfile which grows over time (rsnapshot just appends to the file when it runs).\\ I use ''logrotate'' to keep that logfile trimmed on a weekly basis and keep a few weeks worth of log data. Add this to a new file called "''/opt/etc/logrotate.d/rsnapshot''": <code> |
| /opt/var/log/rsnapshot { |
| weekly |
| rotate 4 |
| copytruncate |
| compress |
| notifempty |
| missingok |
| } |
| </code> |
| |
| I thought it would be nice to have the //slug// send me the log file through email. For this purpose, I have installed the //nail// package. The nail program which gets installed using "''ipkg install nail''" is incapable of invoking a local sendmail, so we have to instruct it to contact a remote SMTP server for email delivery, by creating a file ''~/.mailrc'' containing these two lines (set the "smtp" and "from" to values that make sense to your network): <code> |
| set smtp=smtp-host.inyour.lan |
| set from=slug@inyour.lan |
| </code> Then, create a cronjob that sends the rsnapshot logfile once a day (and pick a time at which it is likely that no rsnapshot process is running to avoid unfinished logs). This is what I added to the //slug//'s crontab file for root using "''crontab -e''": <code> |
| 0 12 * * * echo "Mail from the slug." | /opt/bin/nail -a /opt/var/log/rsnapshot -s "Rsnapshot activity log" you@inyour.lan |
</code> | </code> |
| |
<note warn> I have not managed to make the //slug// send me emails yet ... If anyone knows what I missed, let me know on the discussion page</note> | <note warn> I have not managed to make the //slug//'s cron send me emails yet using sendmail ... all emails seem to piling up in the local mail spool. If anyone knows what I missed, let me know on the discussion page</note> |
| |