Welcome to the new location of Alien's Wiki, sharing a single dokuwiki install with the SlackDocs Wiki.

Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
linux:slug [2009/11/15 17:03] – More explicit examples of commands to enter. alienlinux:slug [2010/04/24 19:20] (current) – More slashes at the end of directories removed. alien
Line 44: Line 44:
 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]].
Line 70: Line 72:
 <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 ====
Line 75: Line 103:
 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 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>
Line 97: Line 124:
  
 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
Line 104: Line 131:
 </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
Line 165: Line 198:
 # mkdir /mnt/thevault/.snapshots # mkdir /mnt/thevault/.snapshots
 </code> Set the proper permissions on all directories: <code> </code> Set the proper permissions on all directories: <code>
-# chmod 0700 /mnt/thevault/.private/ +# chmod 0700 /mnt/thevault/.private 
-# 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> 
-  localhost:/mnt/thevault/.private/.snapshots /mnt/thevault/.snapshots nfs  ro   0 0+  localhost:/mnt/thevault/.private/.snapshots  /mnt/thevault/.snapshots  nfs  ro   0 0
 </code> Now restart the NFS daemon: <code> </code> Now restart the NFS daemon: <code>
 /opt/etc/init.d/S56nfs-utils condrestart /opt/etc/init.d/S56nfs-utils condrestart
 </code> Now mount the read-only snapshot root (happens automatically at boot): <code> </code> Now mount the read-only snapshot root (happens automatically at boot): <code>
-# mount /mnt/thevault/.snapshots/</code>+# mount /mnt/thevault/.snapshots</code>
  
   * In ''/opt/etc/mail/aliases'' add an email alias for user root so that you will receive emails generated from root's cronjobs.   * In ''/opt/etc/mail/aliases'' add an email alias for user root so that you will receive emails generated from root's cronjobs.
  
   * 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 
-01 * * sun    /opt/bin/rsnapshot weekly+30 23 * * *       /usr/local/bin/rsnapshot daily 
 +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>
  
 A backup server using NSLU2, unslung and rsnapshot ()
SlackDocs