Saturday, August 23, 2008

FAIL: Slackware 12.0 - NFS, NAS, rsync


I created an NFS Ethernet with a 4 port router. One of the ports went to a NAS, another to a printer, a third to my desktop and fourth was left free. The point was a LAN which allowed me to use the NAS as a central synch point, something like a cloud server. First, I would synch with my desktop, secondly, when I arrived home with a work laptop, I could plug it into the open router port and synch that also.

NFS was because it's an older service built upon Sun's RPC services -- it's tried and true. Additionally, my systems currently are Linux systems, so why add security and memory problems with SMB or Samba? Ultimately however, I was defeated by a sh*tty NAS enclosure.

Vantec LX NAS (NST-375LX-BK)

I purchased a Vantec NAS enclosure and ran into problems immediately, probably because I didn't research the product in advance. Thinking it would work generically, I installed a dormant 350GB PATA drive into the Vantec. The enclosure has USB and Ethernet ports, but it appears Vantec's brilliant designers made the Ethernet firmware Microsoft protocol exclusive. This meant it was not native NFS and would instead require SMB (Samba). I was faced with installing Windows compatible Samba garbage or using the USB connection. In addition to no network compatibility (except samba), USB speeds are similar to molasses. What a load of crap. For those who want to jeopardize your box w/Samba, here is a forum link with the info of what to do.

Edit: the power conditioning in this box is just a voltage regulator chip; even normal line transients will change power to the enclosed HDD and possibly zorch the data. After I gave up on this box as a NAS, I used it as an external back-up and lost about 100G of data, some of it irreplaceable, eg family photos. I now use only USB powered externals.


A short digression for a rant. Following my above situation, I looked for other options. There is a hideous lack of home-user NAS enclosures running NFS in the US consumer marketplace. In the US, to purchase a NAS that works with NFS one must spend at business levels, about $1000. Interestingly, if one only needs a Windows enclosure, the cost is perhaps $400. Meanwhile, there are many options for inexpensive NFS-serving NAS enclosures in foreign markets, such as the UK. These foreign markets don't require Windows or Samba, so why is NFS so shut-out in the US? Especially when it's understood that Windows and Samba have security vulnerabilities. One has to ask themselves what marketplace and/or government influences would lead to such a situation. Interesting.

NFS, RPC, portmap

Without an NFS box, let's still take a look at what I would have done, if I'd had one. As noted above, NFS lies on top of RPC services. RPC ports are not dedicated, they move around, so we need port mapper as a connection tracker. The portion of NFS which sends commands and acknowledgments between server and client is a normal dedicated port "file" (ports are files in UNIX), port 2049. But NFS uses undedicated RPC ports to move the data payloads, eg. the powerpoint files, the text files, whatever we are moving. The portmap application is necessary for this portion of the transfer. If portmap crashes, data may be lost or unsaved. To see what ports portmap is currently tracking, use, eg...
$ rpcinfo -p

RPC functionality

This tutorial is a good start to setting up the RPC functionality necessary for NFS.
1. The presence of /etc/hosts.allow and /etc/hosts.deny.

portmapper functionality

NFS functionality

1. In function, I've seen that domains have to be the same across the machines. For example, let's say one machine's /etc/HOSTNAME indicates "", and another machine on the same LAN has "". This makes the situation very difficult.

NFS from command line

NFS is essentially a mount, but remote - we mount a drive, or folders from a drive, from another system on the LAN, and it appears as a drive on our current system, though labeled so we know it's an NFS share. We can mount temporarily from command line or make it permanent as part of the boot process.

NFS as an fstab line

NFS directory mounting


NFS requires various ports. The system should be operating smoothly before attempting to add firewall functionality because ports may be affected from the firewall rules. If anything goes wrong, we will know that it was on the firewall side, and not our NFS configuration.

Thursday, August 21, 2008

Slackware 12.0 - Dual Homed

Challenges can arise when a wifi NIC is handling wifi internet access and, in the same computer or "host", an ethernet NIC is operating in a wired LAN (eg, with a printer and backup storage). Since the host exists in two different LANs simultaneously, it is "dual homed". Obviously, two LANS means two routers.

gateway vs. dhcpcd

Check email at Yahoo. The host PC makes this request to Yahoo and Yahoo is outside the host's network, so it needs to use the gateway and the name servers outside the gateway. But when interfaces are being initialized at boot, the dhcp application, dhcpcd, overwrites the /etc/resolve.conf file that shows the IP addresses of these nameservers. So, if we bring the eth0 connection up after the wlan0 connection, our nameservers will be overwritten. To avoid this we do all these things:
ifconfig eth0 down
ifconfig wlan0 up
dhcpcd wlan0
sleep 3
sleep 5
route del -net netmask dev wlan0
ifconfig eth0 up
sleep 3
dhcpcd -R eth0 #-R prevents resolv.conf overwrite
sleep 3

Sometimes,(rare) I have a "UG" default gateway for both wlan0 and eth0 even after these steps. I then remove the extra gateway at the command line:
route del default eth0
A quick verification with "route" shows me the second gateway is gone.
Also there are these files...

loading order

rc.inet1 reads rc.inet1.conf and loads rc.wireless which reads rc.wireless.conf when loading. I don't worry about the rc.wireless.conf, but, in rc.inet1.conf I look for the default gateway line and I change it from "" to the IP of the gateway router.


The final step. We want to be sure everything is running before we lock down ports.

Wednesday, August 20, 2008

Slackware 12.0 - SiS190 eth0 module

Links: sis191 instructions


I connect a hard-wire Cat5 cable from my box (integrated SiS190 NIC) to a known-good Cisco router. Dhcpcd times-out and assigns a default IPV4LL address, eg The network is unreachable. Is it the cable, the router, the NIC, router firmware, OS software?

Unfortunately for my weekend, several hours pass narrowing the options. Eventually, it appears the insertable module for the NIC is from 5/2007 and does nothing. Isn't that nice? The process is explained relatively well here.

Kernel recompiling was required. Since I had no Net on this box, I had to download kernel source on another box and sneaker-net it to the box with SiS191.

Tuesday, August 19, 2008

Slackware 12.0 - Safety Part 1: expectations

high expectations, low knowledge, under-equipped

We typical home pc users combine our computer security system, end-user applications, and our critical data into a single box. Further, we design this arrangement without IT or programming experience. How effective do you believe such a security arrangement is likely to be?

Accordingly, seen in security terms, our home computer systems are an "opportunity". In large organizations, well-paid IT professionals design layers of dedicated security systems to protect workstation computer networks and data is backed up and retained elsewhere. Since we don't have that option, let's at least think about our configuration.

situational awareness - threats

Given that our home systems present opportunities, are there threats which seek to take advantage of them? First, it appears one may assume governments, US or otherwise, can easily penetrate our leaky home systems, and perhaps they do so regularly. It's also likely a large number of civilian entities penetrate our home computer systems. Given the opportunity and the threat, and our typical lack of resources to build a $3-5K layered and ported system, about all we can do is make ourselves a less inviting target than other home machines out there. Let's suppose here we're going to make the effort, where do we begin?

step one - no security

Linux security features sometimes function like shells around processes, sometimes around files, sometimes around ports, sometimes around data streams, sometimes around other things. The security system is complex. The dedicated security servers of the corporate world do this more easily since they operate with firmware or static-linked libraries and have no other applications or data to interfere. But we want applications and data on our home systems. This means we're bound to have permission or authentication problems when we configure complex security functions around desktop applications and web interfaces. Accordingly, I have one rule for a home system prior to activating iptables.chains,tripwire,ssh, really any security function - the system has to work exactly the way it's supposed to work before the security is implemented, and hopefully before it's connected to any network. If we don't have desktop functionality first, is the permission problem we see when activating security related to the security configuration or is it due to the user configuration? We have no way to cut the problem in half. Alternatively, we could bring up our security half before the desktop operations half, but this means we would have to estimate user applications in advance. So the first step of (home) security is to configure the desktop system to run reliably, including all it's peripherals of printers, scanners, cameras, audio inputs, and so on. Subsequently, we will activate our security and the net packages together, and adjust the mix when a desktop application ceases to work due to security layers. Ideally, we should test system applications after adding each security layer.

Monday, August 18, 2008

Slackware 12.0 - CUPS network printer

Here's how CUPS worked-out on a couple different systems connected to a wired ethernet LAN, with a printer attached to the same LAN, and wifi access to the Web on each box (dual-homed boxes).

slackware 12.0 - huge.s kernel patched for non-smp
500 MHz PIII
500 MB Ram
HP1100 LaserJet
Netgear PS 101 MiniServer
Linksys BEFSR41 10/100 router
RTL8139 type card

What works: install

For most of us, the CUPS webtool at  http://localhost:631
simply never works. Not only this, but it waits until the final step in a timely 6-part process to note the failure. For me, it feels more efficient to add printers manually. Perhaps some day all the permissions will align with the stars and CUPS will work. At any rate, there is no limit to the number of printers we can manually add to our workstation.

Lpadmin is the command, but first prepare the printspace:
  • add print group ("lp", in many cases) to the groups for users I want to have print access. Users who are not in lp or whatever, can notprint or cancel print jobs without rooting-up.
  • decide which ppd to use with the printer.
With these two accomplished, try to add the printer:
# lpadmin -p HP1100 -E -v socket:// -m hpijs.ppd
This may return the error that the hpijs ppd file, in this case hpijs.ppd, cannot be copied. Ppd's need to be in the correct format (uncompressed ppd) and directory (/usr/share/cups/model) if lpadmin is to find them and add them.

Foomatic hides and zips their ppds. I finally located them in /usr/share/cups/model/foomatic-ppds/HP. The one I needed was HP-LaserJet1100.ppd.gz. I copied this file into /usr/share/cups/model , unzipped it: "gzip -d HP*", and renamed it hp1100.ppd for ease of loading. Then I ran:
# lpadmin -p HP1100 -E -v socket:// -m hp1100.ppd
The printer was successfully added to the system. Suppose, however, I wanted to try several .ppd files to determine the one with the clearest print and functionality? Ppd files can easily be added and deleted. Simply copy the new .ppd file (let's call this new one eg, another.ppd) into /usr/share/cups/model/ and run:
# lpadmin -p HP1100 -P another.ppd

What works: configuration

Ideally again, one should be able to use the CUPS webtool at  http://localhost:631 for configuration, just as we were supposed to be able to add printers with it. If the web interface is working, use it. If not part two of our work will be to modify the file /etc/cups/printers.conf with the right settings and restart the CUPS server so it reads the file. In /etc/cups/printers.conf one line has different possible structures depending on how the printer is attached. Let's say we've named our device "printername", some possibilities are:
DeviceURI socket://ip.address/printername #LAN
DeviceURI socket://ip.address:ps101name #LAN version2
DeviceURI parallel:/dev/lp0 #parallel port
DeviceURI usb:/dev/usb/lp0 #usb port

I experimented until I determined the correct one for the physical connection which, in my case, was on a LAN. I looked in my router and found my printserver received DHCP at
I navigated there ( in Firefox, and found a GUI interface which allowed me to rename the printserver to any name I desired, but decided to leave it PS101. Accordingly, the successful syntax for my DeviceURI was this one:
DeviceURI socket://
and my final working configuration file went like this:
# Printer configuration file for CUPS v1.3.7
# Written by cupsd on 2008-12-01 04:19
<DefaultPrinter HP1100>
Info HP1100
DeviceURI socket://
State Idle
StateTime 1228132708
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer

After all this, I ran
# service restart cups
in order for CUPS to re-read the /etc/cups/printers.conf file with the new information. I was able to print from all programs.

test prints

While testing printer ppd's, I ran a lot of test prints. Some worked, but the ones that didn't print piled-up in the queue, and the CUPS interface at http://localhost:631 would never allow me to delete jobs. CLI solution to delete print jobs, (assuming CUPS is running, there is no "lpstat" w/out CUPS):
# lpstat -o
provides pending print jobs and the job number eg, "HP1100-1". Then
# cancel HP1100-1
will get rid of the job. Run "lpstat -o" again to verify, if you like.
# lpstat -v [list of installed printers]
# lpstat -d [names default printer, also can specify using this]

xfce4 note

To print from Mousepad and others that use X-settings, xfce printing needs to recognize the CUPS printer. Try printing in Mousepad and see if the CUPS printer is available. If not, configuring xfce4 to CUPS will be necessary. This was simple for me. I simply went to the XFCE menu, then access Settings ->Settings Manager -> Printing System. Once in Printing System, I selected the CUPS network printer and closed the menu. I then opened a Mouspad file to print; sure enough, the CUPS printer appeared in my options.

What is supposed to work (as opposed to all of the above)

First, good CUPS documentation here.
Essentially, one should be able to navigate to CUPS at  http://localhost:631 with Firefox and add printers, manage the print queue, or do other config changes. I never could get the parts to sync enough to add a printer, let alone administer them. Some considerations:
  • GUI authentication: CUPS apparently relies on PAM, Slackware does not provide PAM?
  • parallel: HPLIP is supposedly needed for support if using a parallel port, but not for network printer. I could not get HPLIP to see the parallel port on the legacy system
  • parallel: snmp might be a factor
In the name of gleaning understanding and advancing progress from previously attempted approaches or, at least, of not duplicating effort,here were some initial directions:
1. configure network and verify dhcp assigned print server and slackbox IP's. Let's call these IP's as follows: - Print Server - Slackbox

2. check /etc/rc.d/ - verify rc.cups (and rc.hplip, if it were needed) are 755.
3. is printer plugged in? PS101 plugged in?
4. Firefox to http://912.168.1.101. Blue admin page. Change or leave the name of the PS101, but be sure to write it down - you will need it later in your /etc/cups/printers.conf file. Print a test page to see that the server is talking to the printer properly.
5. Firefox to http://localhost:631 CUPS admin interface. Make sure it comes up.
6. Check that tcp and udp ports 161,162, and 9100 are not locked-down.

CUPS Webtool notes http://localhost:631

1. Try adding the printer with the CUPS webtool. It likely will wait until the (frustratingly) last step in the process and reject your password. Since CUPS uses PAM for password authentication and Slackware doesn't use PAM, I made many many many attempts at editing the /etc/cups/cupsd.conf file to eliminate the password requirement, but it always prompted me for a password in the CUPS webtool. According to the information at this slack site here is how one should proceed:
A. Lets say your name is "doofus" and you declared your SystemGroup in cupsd.conf as "wheel":
lppasswd -g wheel -a doofus
B. Check to be certain:
# cat /etc/cups/passwd.md5 doofus:wheel:01234567890abcde1234567890abcde12
C. Now restart CUPS and go back to the webtool in Firefox and add the printer:
#/etc/rc.d/rc.cups restart
I never got it to work; the password was always rejected and I could never add a printer.


SNMP (Simple Network Management Protocol) is a powerful process originally designed to simplify web management. Many processes take advantage of SNMP functionality and one of them is HPLIP

If hp-setup doesn't work, then the road may be long. Try using SNMP to determine if the kernel can see the printer at the nework address:
snmpwalk -Os -c public -v 1 ip.address.of.printer
Per this site HP tshoot, the response should be something which shows the manufacturer,or SNMP may not be installed correctly. This means working with the /etc/snmp/snmpd.conf file.

Slackware 12.0 - install 1


Moving from Debian and Debian-based hybrids (eg. Ubuntu) means a different initialization configuration. For me, this was for the better: the straightforward /etc/rc.d layout in Slack (and its hybrids - eg. Zenwalk) is clean and almost intuitive. Another bonus was learning that Slackware doesn't use PAM. Let's look at Slack 12.0 install.

Older Machines

1. boot with non-smp kernel big.s
2. cfdisk, mke2fs, and mkswap per taste.
4. activate disks, including swapon. Skip formatting (done in #2)
5. install from CD's or DVD but don't configure the network
6. reboot, run the patch for non-smp.
7. add group 1000 and user 1000, do a genfstab, etc.
8. reboot, login, and further configure users, groups, fstab, inittab, profile, visudo, modules, other initialization.
9. build nvidia drivers if necessary
10. build wifi drivers if necessary (madwifi, ndiswrapper, other)
11. a second look at modules to /etc/rc.d/rc.modules and any associated commands to /etc/rc.d/rc.local
12. reboot, check dmesg -tail, verify wifi or eth0 (eg. with "route"). To make permanent see here. If box is dual-homed, alter network files appropriately.
13. download and configure xorg.conf or copy premade to /etc/X11/
14. copy /etc/X11/xinit/xinitrc to ~.xinitrc and add desired Windows Manager line at end, eg exec dbus-launch twm
15. reboot, attempt $ startx and tune.


No need to download and compile a driver module if one came with distro: Check here:
ls /lib/modules/

Atheros AR242x 64 (5007 chipset)

Memory location on my card for this is 53100000. The instructions here were crucial. The ath5k module doesn't apparently work well in Satellites, however it's described here, and it appears the ath5k will eventually be the way to go. For now, the steps seem to be:
  1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
  2. reboot and lsmod - verify ath5k is gone
  3. download madwifi-hal- , or the newest one there, make, and install.
  4. reboot again and lsmod again
  5. # iwconfig ath0

Atheros AR5005G

download latest madwifi, eg madwifi-, then the usual
$ tar -xzvf madwifi*
$ cd madwifi*
$ make
# make install
# modprobe ath-pci

RaLink RT2600 802.11 MIMO
1. download latest ralink rt61 driver from ralink support.
2. $tar -xzvf 2008*
3. $cd RT61_Linux*
4. $cp Makefile.6 Makefile [kernel 2.6.x]
5. Alter module rtmp_main.c , by commenting out (around the bottom, line ~900):
return pci_module_init(&rt61_driver);
and replace it with:
return pci_register_driver(&rt61_driver)
6. Their "configure" file is not executable, so change it, then configure and make the module.
$chmod 755 Configure

7. Make a directory where the module will locate configuration info and put these info files in it.
# mkdir /etc/Wireless/RT61STA
# cp rt2561.bin /etc/Wireless/RT61STA/
# cp rt2561s.bin /etc/Wireless/RT61STA/
# cp rt2661.bin /etc/Wireless/RT61STA/
8. The last file to go into that config directory may have CTRL+L line ends and we have to be sure these are eliminated: Use $dos2unix rt61sta.dat (or use sed). This file has the particulars for our LAN and WEP.
9. Copy that file to where the others are at:
#cp rt61sta.dat /etc/Wireless/RT61STA/
10. Send the module to the kernel's module folder:
#cp rt61.ko /lib/modules//misc/
11. Tell the kernel where to find the module by adding a line in /lib/modules//modprobe.dep
: "/lib/modules//misc/rt61.ko:"
12. Load the kernel:
#modprobe rt61

1. provide permanence via /sbin/modprobe ath-pci to /etc/rc.d/rc.modules and any configuration for it (eg. iwconfig ath0 essid "loser") to /etc/rc.d/rc.local.
1b: in the case of Ralink /sbin/modprobe rt61 to /etc/rc.d/rc.modules.
2. further modify /etc/rc.d/rc.local to be sure card comes up. Last line for the card: iwconfig ra0 up or iwconfig ath0 up
3. reboot and "dhcpcd ra0" or ath0, check with "route" and a ping.