My personal notes on all things technical and factual....

Sat, 12 Sep 2009

/Linux/Debian: Quick Start Networking on Debian

This simple tutorial is meant to show the basics of how to get networking working on Debian Linux from the command line, and assumes at least that your network card has been recognized, the appropriate kernel module has been loaded, and a viable network interface initialized for the network card. This should all happen automatically on boot or card insertion, and if it does not, getting your card to work is unlikely to be a simple task.

(Note that there are various GUIs that try to make networking "easy" in Linux, but in my experience they do not work very well, and once you know the command line method you will rarely crave a GUI....)

All commands in this tutorial require a root terminal. The commands we are going to use are:

ifconfig: query (and modify) status of network interfaces
ifup: activate a network interface
ifdown: de-activate a network interface
iwconfig: query (and modify) the status of a wireless network interface
iwlist: find out what wireless access points are within range

To find out what live network interfaces you have, enter ifconfig:

In the above example, "lo" is the loopback interface (important but irrelevant to this tutorial) and "eth1" is the network interface with the outside world. In eth1, note:

inet addr: 192.168.8.6

which tells you that eth1 has an IP address (and in fact is my wireless card as I write this). Though not always strictly true, for the purposes of this tutorial, if there is no IP address, the network is not working. Now enter "ifconfig -a":

Note that "eth4" has now joined the party, and does not have an IP address. eth4 in fact is my on-board wired network card which I am not using and have turned off. "ifconfig" shows all active network interfaces, and "ifconfig -a" shows all network interfaces, including those that are not turned on.

udev is the piece of software that is supposed to assign a unique network name (eth0, eth1, eth3, wlan0, etc.) to every network card plugged into your system, which should remain stable over reboots. (Of course, you can change this behavior and even choose what name is assigned to a given card.....)

Now have a look at the file /etc/network/interfaces with your favorite text editor. Mine looks like this:

Interfaces with an "auto" line should be started automatically on boot, in this case lo and eth1. "man interfaces" will tell you lots more about the contents of this file, but for the simplest case,

iface eth4 inet dhcp

specifies the configuration of the eth4 wired interface: the network will be queried for a dynamically assigned IP address via DHCP, and

will do the same for the eth1 wireless interface. The 2nd and 3rd lines give the wireless card permission to connect to any wireless access point that it can find. (Of course, one can also not use DHCP and assign a static IP, and also specify the access point.... not covered here.)

With a /etc/network/interfaces file with the above contents, at the root prompt issuing

ifup eth1

will start the wireless interface. If the card finds a willing and appropriately configured access point, ifconfig should show eth1 as having an IP address. You can find out more about what is going on with your wireless card (and reconfigure it) with the iwconfig command:

You can also have a look at what other access points the wireless card is seeing with the iwlist command:

Just one access point in this neighborhood....

Suppose this is your home configuration, and at work you have a wireless network called 2WIRE162 protected (not very) with a WEP key. Add the following stanza to your /etc/network/interfaces file:

In our /etc/network/interfaces file we have three physical network interfaces (lo, eth1, and eth4) and now we have added a "logical" interface called "work". A physical interface corresponds to a network card ("lo" is a special case that does not) and a logical interface *can be* associated with any physical interface. Ie.

ifup eth1

will cause eth1 to connect to any open access point in the vicinity, whereas

ifup eth1=work

will permit eth1 to only connect to an access point with an SSID of "2WIRE162" and a WEP key of "0642243084".

WPA encryption, unlike WEP, provides real security, but is a little complicated to setup and will not be covered here. If you want WPA, you need to configure a piece of software called "wpasupplicant".

posted at: 13:13 | path: /Linux/Debian | permanent link to this entry

Sat, 23 May 2009

/Linux/Debian: Software Package Management in Debian (and Ubuntu)

I particularly dislike graphical package managers, as they are all seem slow and, I think, not much easier to use then the command line. Here is a little quick start guide to using the command line to install and remove software in Debian or Ubuntu:

Search for software:

apt-cache search {space separated list of key words}

Display information about a particular package:

apt-cache show {name of package}

Upgrade: update your software list and then upgrade all installed software to the latest version:

apt-get update
apt-get upgrade

Install a defined list of packages:

apt-get install {space separated list of package names}

wajig, a useful utility: install wajig and less:

apt-get update
agt-get install wajig less

Then "wajig list-commands", which will produce output that is more then one page long, so even better is:

"wajig list-commands | less"

(Exit less by entering "ZZ")

"|" is the "pipe" operator, found on the same key as "\" on my keyboard, and is one of those whiz-bang UNIX features that, after you accumulate a short list, will leave you quite disinterested in ever going back to Micro$oft Windows.

Hold a package and exclude it from automatice upgrades:

'echo -e "python-pysqlite2 hold" | dpkg --set-selections'

where python-pysqlite2 is the package to be held. Thereafter, when one performs an "apt-get upgrade" the held package appears in the "following packages have been kept back" section, and requires a manual "apt-get install python-pysqlite2" to re-instate the latest version.

Revert a package to an older version:

For instance, if you track "testing", but want to use the occasional unbroken package in "stable", your "/etc/apt/sources.list" should contain the following two lines:

deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb http://ftp.us.debian.org/debian/ stable main contrib non-free

"testing" will take precedence over "stable" as it appears first in the list. Now suppose a just updated piece of "testing" software is broken. First find out what versions are available in your current archive:

apt-cache policy python-pysqlite2

To install an older version:

apt-get install python-pysqlite2=2.4.1-1

where the version identifier comes after the "=". And now, to prevent your just downgraded package from being clobbered by automatic upgrades, put the package on "hold", as described in the previous section.

posted at: 08:35 | path: /Linux/Debian | permanent link to this entry

Tue, 06 Jan 2009

/Linux/Debian: Debian: How to Modify a Source Package / Build a New Binary Package[1]

Downloading, building, tweaking, and rebuilding a source tarball is not that difficult a concept for me at this point. Debian, however, has a very sophisticated (complex? obtuse? But I still love Debian....) packaging system.

Quick & Dirty Method[5]:

Say I am trying to debug something with the cron package:

apt-get build-dep cron
cd /to/where/you/want/to/install/your/source
apt-get source cron
cd cron-3.0
modify the code
DEB_BUILD_OPTIONS=debug,nostrip fakeroot debian/rules binary
debi

where dpkg-buildpackage builds a .deb and places it one directory up and debi installs the package. DEB_BUILD_OPTIONS are optional, but extremely useful if you are going to use gdb for debugging.

Note that the package version is not changed with this method, and the next time you run "apt-get upgrade" it will want to replace your debug version of the package with the repository version.

Patches & Versioning:

Sorting out how to mess with source code using the "Debian way"[3] is not at all transparent. Roberto Sanchez' "Debian Package Customization HOWTO"[4] is better:

Suppose someone sends you a patch that you want to test. Here is how you would obtain, patch, and build the source to create a new .deb with a unique version number, ready for installation:

apt-get source foo
cd foo-1.0
patch -p0 < /path/to/patch/file/ # apply patch to source
debchange -nmu  # See note below
sudo apt-get build-dep foo # install build dependencies
dpkg-buildpackage # build binary package from source

"debchange -nmu" will bring up the changelog in your default editor. In addition to modifying the text of the log, it is also possible to modify the package version number in the header of the changelog entry. Sanchez[4] recommends decrementing the version, adding a ".0.0" to the end, then adding a "name.0" to that. "name.0" is the part you use locally to track local changes. The preceding decremented-version.0.0 tries to ensure that any packages that appear in the repository afterwards will take precedence over the local package, so that upstream updates get installed (assuming that is what you want).

You should find your new .deb one directory up (..) with the version number as specified in the changelog.

Note that you might optionally want to put the source under the control of the git[2] revision control system if you are going to make modifications yourself and submit patches.

[1] http://www.debian-administration.org/articles/556
[2] http://blog.langex.net/index.cgi/Coding/git-basics.html
[3] http://www.debian.org/doc/maint-guide/
[4] http://people.connexer.com/~roberto/howtos/debcustomize
[5] http://women.debian.org/wiki/English/BuildingTutorial

posted at: 13:24 | path: /Linux/Debian | permanent link to this entry

Tue, 16 Dec 2008

/Linux/Debian/WPA: Easy wpasupplicant on Debian

A little poking around revealed that this file /usr/share/doc/wpasupplicant/README.Debian.gz was the secret sauce for getting wpasupplicant painlessly functioning on a Debian machine.

Like with wireless-tools, Debian has integrated wpasupplicant into the /etc/network/interfaces file.

To talk to a simple WEP-encrypted access point, this is the stanza I am using in /etc/network/interfaces:

auto eth1
iface eth1 inet dhcp
   wpa-ssid linksys
   wpa-key-mgmt NONE
   wpa-wep-key0 8453017892
   wpa-wep-tx-keyidx 0

To achieve the same with wireless-tools instead, I have this stanza:

iface home inet dhcp
   wireless-channel 11
   wireless-mode managed
   wireless-key 8453017892
   wireless-essid linksys

and of course, "ifup eth1" and "ifup eth1=home" will both connect, the former using wpasupplicant and the latter using wireless-tools.

Of course, the whole point of wpasupplicant is to talk to a WPA-encrypted access point. Stay tuned until I get a chance to try it again....

posted at: 08:10 | path: /Linux/Debian/WPA | permanent link to this entry

Sun, 07 Sep 2008

/Linux/Debian: Running a Blosxom Site on Both Desktop and Server

The goal, obviously, is to edit the site locally on my desktop where everything is very fast and convenient, and then periodically sync with the copy of my site on the server. This also has the advantage of automatically enforcing backups.

Of course, one needs Apache installed on the desktop to see what is going on with the site as you edit. I started by installing the (Debian) libapache2-mod-fastcgi and libapache2-mod-perl2 modules. Then copied my whole blosxom site into a sub-directory of ~/public_html.

Then, when I pointed my browser at the blosxom directory, all it would do would display the blosxom.cgi script without executing it. If I executed the script from the command line, ie "./blosxom.cgi", it would actually generate the home page html nicely. So there was clearly something wrong with the Apache configuration.

As it turns out, Debian installs Apache with cgi scripts restricted to one system directory. Apache refuses to execute them anywhere else, like in /home, for instance. The Apache website[1] turned out to be the best source for a solution. I added the following code:

<Directory /home/*/public_html>
     Options +ExecCGI
     AddHandler cgi-script .cgi
</Directory>

to /etc/apache2/sites-available/default, and it was fixed! Onto the next problem....

The path to my blosxom site is different on my desktop and on my server, which gives me problems in a couple of different places.

The easy one is the link to my CSS style sheet in head.html. I made this link absolute to the copy on my server, ie.

<link rel="stylesheet" type="text/css"
href="http://blog.langex.net/bloxsom/2c-lc-static-layout.css">

So now both copies of the site pull the style sheet off the server.

Slightly harder are the several paths hard-coded into blosxom.cgi. To work around this, I settled for two versions of the script. I use unison-gtk[2] to synchronize between desktop and server, so that after forking the two copies of the file I just tell unison to "ignore" the difference in the future (ie. it does not sync that file). Furthermore, to ensure the server copy gets backed up, I hard linked it to another file name, ie.

ln blosxom.cgi blosxom.cgi.server

which unison then dutifully keeps a copy of on my desktop.

I have some hard-coded menu links in head.html that now just work on the server, not on the desktop, but I consider that to be a minor issue....

[1] http://httpd.apache.org/docs/2.0/howto/cgi.html
[2] http://www.cis.upenn.edu/~bcpierce/unison/

posted at: 15:48 | path: /Linux/Debian | permanent link to this entry

Home

Contact

Resumé / C.V.

Links

Categories:

Archives:

Subscribe XML RSS Feed

Sat, 12 Sep 2009

Sat, 23 May 2009

Tue, 06 Jan 2009

Tue, 16 Dec 2008

Sun, 07 Sep 2008