Niels Horn's Blog has moved!

New blog – Old blog…

2010-01-04T13:18:00.002-02:00

This blog has moved to my personal site: http://blog.nielshorn.net. Please update your bookmarks!

All existing posts have been imported into the new blog and the old copies will stay here to guarantee that older links continue to function.

Since the update of all DNS servers on the internet may take up to 24 hours, please try again later if the link does not work yet.

2010...

2010-01-02T18:54:00.002-02:00

2009 is gone, 2010 has started.

Lots of sad news here in Rio, after all the rain that has fallen here over the last few days, but life goes on :(

In just a few days I will officially be on vacation, so I might not have too much time to write here, but I still have some raw material I want to publish, like some experiences with nagios (working very fine here), ntop, cacti, zabbix, etc.

And I'm working on some lay-out changes for my blog, so be prepared to see some novelties here :)

Happy New Year!

Using a 32-bits program in a 64-bits Linux environment

2009-12-31T14:13:00.002-02:00

When Slackware released its first test version of Slackware64, I installed it on a separate partition to try it out. I was immediately impressed by the performance boost of some programs, especially some graphic programs I use.

Since I compile most programs that are not available on a standard Slackware installation from source, I didn't have too much trouble switching completely from 32-bits to 64-bits when the official release came out.
But for some programs the source code is not available. The original author / site may have disappeared, or it might simply be "closed" software.
I had this problem with some older programs I still used and they simply would not run on Slackware64. The error they normally return is:

<program_name>: No such file or directory

This error actually means that the binary file is looking for some (32-bits) library it cannot find, simply because they do not exist on pure 64-bits Linux installations.

One option was to go "multi-lib" - install the 32-bits libraries on my Slackware64 box. But I did not want to go that way, as I preferred to keep my installation as "pure" as possible.

So I started looking for another solution, and on the LinuxQuestions.org forum someone pointed me to statifier.

Statifier simply combines the binary executable with all the libraries it needs into one (big!) executable "semi-static" file. I won't go into the details how it does that (because I also do not understand all the details...), so if you want to know more, check out the site of the author.

The only problem is that you will need a 32-bits machine where your binary works fine, to "statify" it. I still had my 32-bits Slackware partition, so no problem for me here.

Statifier is open source software, so you can build it yourself, or get my package for Slackware on my site.

After installing or building Statifier on your 32-bits machine, you can use it to "statify" your 32-bits binary like this:

$ statifier <binary> <new_binary>

Remember that the result will be a lot bigger than the original, as it includes all the libraries that are normally loaded dynamically. As an example, I used it on "l3p", a small program to convert LDraw files to POV-Ray files, only available in a 32-bits version.
The original file was 140K, the statified version is 2.7M :)
But it solved my problem and I can use l3p on my 64-bits Slackware64 installation!

If you want to use l3p on Slackware64 as well but this is all too technical for you, you can get the statified version of l3p as a Slackware package from my site.

"lgeo" Slackware package available

2009-12-31T12:19:00.002-02:00

After some requests, I created a Slackware package with the lgeo parts library. It can be downloaded from my site.

If you prefer, you can download the library from the author's website and use the SlackBuild to create your own package.

Updated LDraw_data package available

2009-12-25T12:40:00.003-02:00

I created an updated package with the LDRAW Library of Lego pieces that includes all parts up to September, 16th, 2009.

The "unix-complete" file from ldraw.org has not been updated for years, so this package was based on the Windows file "complete.zip" but can be used without any problems under Slackware.

As always, the package can be downloaded from my site.

Lego & POV-Ray on Linux

2009-12-24T16:58:00.017-02:00

Some time ago I promised to give some basic instructions on how to create nice images of Lego constructions with POV-Ray on Linux. Now that Christmas is arriving, I finally found some time to convert my own instructions into something that can almost be called a "tutorial" :)

What will you need:

LeoCAD - to "build" your constrution

(optional) a viewer program, like LDView or ldglite

l3p - to convert the .ldr (LDRaw) file to .pov (POV-Ray)

(optional) The "lgeo" parts collection

POV-Ray - the "Ray-Tracer program"

If you use Slackware, you can find packages for all of these on my site and SlackBuilds for all except 3 on www.slackbuilds.org. For many other Linux distributions packages are available in their repositories.

First step - Build something!

If you do not have any LDraw file yet with a Lego creation, then now is the time to make one.
As an example for this tutorial, I built a little penguin, based on the instructions here, with LeoCAD:

Save your creation with LeoCAD as a ".ldr" file ("File" - "Save as" from the menu). The resulting file in my case was:

0 Model exported from LeoCAD
0 Original name: Penguin.lcd

 1 14 -50.00 -0.00 -60.00 -0.00 0.00 1.00 -0.00 1.00 -0.00 -1.00 -0.00 -0.00 3002.DAT
 1 15 -50.00 -24.00 -60.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 15 -50.00 -48.00 -60.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -50.00 -24.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -70.00 -48.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -30.00 -48.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -50.00 -72.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 14 -50.00 -72.00 -70.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3003.DAT
 1 0 -50.00 -96.00 -50.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3003.DAT
0

Second step - View your model with ldglite or LDView

This step can be skipped, but it is a nice test to check if the programs can find all the LDRAW parts on your computer. LeoCAD uses its own parts library, so being able to view it there does not necessarily mean that the LDRAW library is accessible.

This is how the penguin looks like in ldglite, a simple but very fast program to visualize your creations:

A second option is to use LDView, a very nice and very complete program to visualize your creations. It creates a more realistic view of the model, with some shading effects:

Third step - Ray-Tracing

So the images created by LDView are nice. But we want something even better! Enter POV-Ray, a very professional Ray-Tracing program that is completely free.
It "traces" light-rays, by tracing paths of "light particles" from one or more light sources, bouncing off surfaces and reflecting into the lens of a camera.

So we define the position and colors of the light sources, the position and angle of the camera, the types of surfaces (smooth, reflective, rough, etc.), etc.

Sounds complicated? Well, there is a very nice utility called l3p that tries to do most if it automatically to help us get started. l3p reads an "ldr" file, guesses the best position and angle for the camera so that the whole creation will fit in the image, and sets up three light sources around the model. Then it creates a .pov file that can be read by POV-Ray.

l3p needs to know where the LDRAW library is stored on your computer. This can be set by the LDRAWDIR environment variable like:

$ export LDRAWDIR=/usr/share/LDRAW

Put this in your start-up script like ~/.bash_profile (if you use bash for a shell).

Enough theory, let's create our first .pov file:

$ l3p -o Penguin.ldr

This reads the "Penguin.ldr" file we created and writes a "Penguin.pov" file in the current directory.
I used just one option - "-o" - which instructs l3p to overwrite Penguin.pov if it already exists, since we'll perform various tests before we get the final result.

Now let's run POV-Ray to transform the .pov file into an image:

$ povray +OPenguin.png +FN +P Penguin.pov

The options here mean:

+OPenguin.png - Output will be Penguin.png

+FN - Format will be a PNG file

+P - Pause after creating the image, showing the result on the screen

The result should look like this:

For a first test, it's just about "OK"... But we can do better than this!

Since in most tests we'll run l3p and povray as a sequence, we'll put both commands on one line like this:

$ l3p <options> && povray <options>

The "&&" means that the next command is only executed if the previous terminated without error.

So let's try:

$ l3p -b -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +P Penguin.pov

What did we add:

-b - add a standard blue background to replace the black void

+W640 - Create the image with a width of 640 pixels instead of the standard 320

+H480 - and a height of 480 pixels instead of 240

The result should look like this:

Let's improve the image a bit more:

$ l3p -b -q4 -bu -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +A +P Penguin.pov

The new options are:

-q4 - Quality level 4, this includes the "Lego" name on the studs

-bu - Create "bumps", this makes the surfaces more "uneven", or more realistic

+A - Anti-aliasing, this prevents those "jagged edges"

This should be the result:

Advanced options

As I wrote in the beginning, l3p automatically guesses the best position and angle for the camera and light sources. But we can change them as we please.
Let's try something:

$ l3p -b -q4 -bu -cg40,45 -cpct10 -f -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +A +P Penguin.pov

I included two new options:

-cg40,45 - Put the camera at "globe" positions 40° latitude and 45° longitude (the default is 30,45 so we put it a bit "higher")

-cpct10 - move the camera back 10%, so that the object is not so close to the edges of the image

-f - put a "floor" under the penguin instead of letting it float in the sky, so that we can see the shadows of the light sources

Here is the result:

You can play around with the position of the light sources using the "-lg" option. I'll leave this as an exercise! :)

There are many more advanced options to try. Type "l3p" without any options to see the complete list! If you have a good tip, feel free to post a comment so that I can learn something new.

Using the lgeo library

The images we created with the standard l3p + povray combination look quite good, but when we enlarge the images, the pieces look a bit unrealistic, with edges that are too sharp, etc.

Enter the "lgeo" library of pieces...

The lgeo pieces are specially designed for use with POV-Ray, with more realistic edges, surfaces, etc. l3p can automatically replace all LDRAW pieces with lgeo pieces if a substitute is available (any many are available, at least for the more "standard" pieces).

We just need to include the "-lgeo" parameter (and have the lgeo library installed and "readable" by povray - this needs some configuration...).
This created a nice image of our Penguin at a larger size:

$ l3p -b -q4 -bu -cg40,45 -cpct10 -f -lgeo -o Penguin.ldr && povray +OPenguin.png +FN +W1280 +H960 +A +P Penguin.pov

And this is the result (click on the image to see the full-scale picture):

As you can see, the studs and the edges look more realistic in this picture.

Have fun!

LDView error "libboost_thread-mt.so"

2009-12-21T09:21:00.002-02:00

For those who use LDView on Slackware-current and noticed that it suddenly stopped working: the problem is in the latest update of the "boost" library:


+--------------------------+
Thu Dec 17 20:51:37 UTC 2009
...
l/boost-1.41.0-x86_64-1.txz: Upgraded.

This latest update does not include the *-mt (=multi-thread) libraries, as the "normal" version is already multi-threaded.

The solution to get LDView working again is simply rebuild it from the SlackBuild:
- Download the SlackBuild script & untar it
- Download the source for LDView
- run the SlackBuild as:
# BUILD=2 ./LDView.SlackBuild
- use upgradepkg to upgrade your LDView

QComicBook 0.5.0 released

2009-11-30T21:50:00.002-02:00

Today (*) a new version of QComicBook was released - 0.5.0. The release announcement can be read on freshmeat.

I submitted a new SlackBuild script to SlackBuilds.org. The previous one, for version 0.4.4, won't work as the author has changed to using cmake.

If you can't wait for the SlackBuild to be approved, you can download complete packages from my site - both for Slackware 32 & 64 bits.

* Actually, today or yesterday, depending on your timezone! :)

Monitoring your network and servers

2009-11-29T18:22:00.003-02:00

I've been busy over the last few weeks evaluating some software to monitor servers, network utilization, etc. I have tested several programs and ended up using three: nagios, cacti, and ntop.

All of these are free & open software. For nagios and cacti you can download SlackBuild scripts from slackbuilds.org maintained by me. For cacti, if you prefer a complete package, you can download one for Slackware here.

For ntop, I adapted a SlackBuild originally written by Michiel van Wessem to install the newer 3.3.10 version. The ntop authors decided to automatically download & install some dependencies (Lua + GeoIP), even if you already have those installed. Since this is a very bad idea (they install it the way they like, while with Slackware YOU are supposed to be in control), I adapted their 'configure.in' and 'Makefile.am' scripts to simply check if those programs are installed and exit if they are not.
Then you can install them the way you like (and following the normal standards) and install ntop afterwards.

With Michiel's permission, I submitted a new SlackBuild script for ntop so SlackBuilds.org that is currently in the pending queue.

Over the next few days / weeks I hope to have some time to elaborate on these three packages and write some hints on how to install and configure them.

Reading Comics on your screen...

2009-10-15T21:52:00.003-03:00

If you like to read comic books you might know about the enormous collections of digitalized copies that float around the internet. Normally they are in '.cbr' or '.cbz' format, actually simple rar'd or zipped collections of images.

To read them on your computer, you can either unpack the file and use a standard image viewer, or find a special program to open the .cbr or .cbz files and display the "pages" of the comic.

For Linux you can use QComicBook, a very nice program that uses the qt4 library of KDE4 (but qt4 can also be installed on systems based on Gnome, Xfce, etc. - you do not need the complete KDE environment):

You'll get various zoom modes (page, 2-pages, japanese, rotate, full-screen, etc) to enjoy your comics wherever you are. I like to take some with me on my trips, so that I can read them at night in the hotel, etc.

If you use Slackware, you can get packages for both the 32 & 64 bits versions on my site.

Lego and Linux (part 5)

2009-10-11T12:39:00.003-03:00

After exchanging a few e-mails with the author, I have managed to build Slackware packages for LeoCAD, both 32 and 64-bits versions.
LeoCAD is a wonderful piece of software to create your own Lego constructions virtually on your computer - with an unlimited amount of pieces :-)
It can import and export LDR (LDraw) files, and export to POV-Ray for creating fantastic images (see my previous post about POV-Ray).
Here is a screenshot of LeoCAD running on my 64-bit desktop:

The packages can be downloaded from my site, where more screenshots can be seen as well.

Lego and Linux (part 4)

2009-10-06T00:46:00.005-03:00

Today I finished the Slackware packages for POV-Ray, the Persistence of Vision Raytracer, a fantastic free tool for creating stunning 3D images.
It can be used also for creating beautiful images of your Lego creations. In a future post I might write a small "how-to" with step-by-step instructions, but here is a small example:

As always, the packages can be downloaded from my site.

Lego and Linux (part 3)

2009-10-04T23:43:00.005-03:00

LeoCAD is not so simple as I thought... The 64-bit version compiles after some patching, but it crashes horribly with some basic things.
While sorting this out, I built packages for ldglite, a little program to view and edit LDraw files. It can be called from the command line also to create images of your drawings.
Here is an example of my elevator:

The Slackware packages can be downloaded from my site.

Lego and Linux (part 2)

2009-10-03T15:36:00.004-03:00

I finished building the Slackware packages for LDView 4.1 (Beta 1).

There are just two dependencies:
- tinyxml
- LDraw_data (the files with all the different Lego parts)

All packages can be downloaded from my site.

As the original meaning of Lego says: Play well!

Next challenge: building LeoCad...

Rio 2016

2009-10-02T21:55:00.002-03:00

The city where I live - Rio de Janeiro - will host the 2016 Olympic Games.
If you want to see some nice images of the place where I live, check this video:

Lego and Linux

2009-09-29T21:30:00.006-03:00

I am currently in the process of building some software on Linux for viewing and building Lego projects.
The first program I have been successful with is LDView, a very nice tool to visualize LDraw files.
I have it working on Slackware 13.0, both 32-bits and 64-bits. It is still a bit of a "hacked" installation, as it requires some fiddling with parameters and recompiling packages. But I plan to put a package on my site as soon as it is in a decent state and submit a SlackBuild for those who prefer to build their own version.

Here are two screen shots, one from the included model and another from my Lego Elevator:

New TRS-80 emulator for Linux

2009-09-26T16:30:00.006-03:00

Mark Grebe released sdltrs, a new emulator for the TRS-80 Model I/III/4/4p for Macintosh, Windows and Linux. It is based on xtrs, but uses the portable sdl library. It has on-screen options to change disks, cassettes, etc.

Packages for Slackware 13.0 are available on my site:

sdltrs-1_0_0-i486-2_nhh.tgz (32-bits)
sdltrs-1_0_0-x86_64-2_nhh.tgz (64-bits)

As always, have fun!

A year of blogging

2009-09-26T08:56:00.002-03:00

It has been a year today I started this blog, so I thought it was about time to change the lay-out a bit.
I made it more-or-less like my homepage, so that people feel, well, "at home" :)

GUI for Hercules on Linux

2009-09-07T23:57:00.003-03:00

Today Jakob Dekel released the first beta version of Hercules Studio, a GUI front-end for Hercules - the System/370, ESA/390 and z/Architecture emulator.

On his site you can find pre-built packages in RPM and DEB format.
For us Slackware users, I created Slackware packages as well, after getting some extra information from a very friendly Jacob Dekel.

The packages for Slackware, both 32 & 64 bits versions, can be downloaded from my site here.
The stable 3.06 version of Hercules is not prepared for a Linux GUI, so you will need the latest svn snapshot, also available as a Slackware package on the same page.

The result can be seen here:

Slackware packages for Hercules

2009-09-06T23:39:00.005-03:00

I have received a few requests for pre-built Slackware packages for the Hercules System/370, ESA/390 and z/Architecture emulator.

I have used Hercules for some time now to run Slack/390 and had already created my own package, but it was not really up to the right standards to be published.

But, with the release of Slackware 13.0 I have reorganized some of my packages and built new ones following the guidelines of SlackBuilds.org.

The result can be downloaded from my site:

hercules-3.06-i486-1_nhh.tgz (32-bits version)
hercules-3.06-x86_64-1_nhh.tgz (64-bits version)

xtrs (TRS-80 emulator) on Slackware

2009-09-05T17:47:00.007-03:00

My first professional work with computers was done on a Tandy / Radio Shack TRS-80 Model I. I still have that machine but have not powered it up for at least ten years, since I do not have a working monitor anymore.
But thanks to the various emulators that are available, I can still run the old programs whenever I need or want to.

Since my desktop runs Slackware Linux, the emulator I use is xtrs. It is small, fast and emulates the Model I, III, 4 and 4p. I have had all these models and still have a Model 4p in reasonable condition.

As every good Linux program, xtrs is distributed as open source, for the end-user to compile.
This has never been a problem to me, but not every TRS-80 fan might be happy about this.

So, after the newest release of xtrs in June, I put on my to-do list to make a 'Slackware-package', so that at least Slackware users can run xtrs installing a simple package without any compiling.
Since my to-do list is quite extensive, it took some time for this task to arrive at the top, but today I finally managed to get it done.

The result is available on my homepage, in two versions:

xtrs-4.9d-i486-2_nhh.tgz, the 32-bit version
xtrs-4.9d-x86_64-2_nhh.tgz, the 64-bit version (for Slackware64)

Both have been tested with Slackware 13.0 but should work fine on 12.x as well, and probably some older versions.

For those who prefer to compile their own software, I submitted a SlackBuild to SlackBuilds.org but it is pending for approval at the moment.

Here is a screenshot of xtrs emulating a Model III running NEWDOS/80:

And this is the Model I running the famous Dancing Demon:

Overview of all Slackware versions

2009-08-29T18:04:00.003-03:00

With the release of Slackware 13 this week, I updated my page with all the versions that have ever been released of Slackware.
All information has been retrieved from official sources, like the ChangeLogs from the original versions I have.

The list includes the official release dates, versions of the included kernel, desktop environments, etc.

I you find anything inaccurate, please tell me, stating your sources!

Flexible scheduling

2009-07-23T18:53:00.004-03:00

As explained in my previous post, I needed a flexible way to schedule a small script to run, with variable parameters.

The basic requirements were:

simple to configure (no messing in crontabs)

flexible enough to have different schedules on different weekdays (on Sundays a job should be started at another time than on Mondays, for example)

should offer the possibility to start different jobs at different times

I want a log of all commands executed

For instance, I need the command "foo start 1234" to run every day except Sunday at 23:00h, and "foo stop 1234" always at 01:00h.
I also need "bar load 1 2 3" to run every Wednesday at noon and "bar load 4" every other weekday at noon.

And, as I am a Slackware fan, I want to do all configuration by changing a text file. No graphical interface please, as my servers do not even have X installed.

So the challenge was there :)

Using cron
Now I thought of a solution how these scripts should be started or controlled.
The standard crontab (in /var/spool/cron/crontabs/root) could probably control everything I needed, but it would be a cumbersome task to change it every time. But - on the other hand - I did not want to substitute cron, as it does a nice job scheduling simple daily or monthly tasks.

So I decided to use cron to start my own scheduler. As an interval I choose a five minute period, as that would be accurate enough for me. I don't need any job to start at 12:42 exactly, 12:40 or 12:45 if good enough for me.

My script to check all schedules was named "sched5" and I added the following lines to the crontab:


# Special 5-minute-interval job
0 * * * * /usr/local/sbin/sched5 1> /dev/null
5 * * * * /usr/local/sbin/sched5 1> /dev/null
10 * * * * /usr/local/sbin/sched5 1> /dev/null
15 * * * * /usr/local/sbin/sched5 1> /dev/null
20 * * * * /usr/local/sbin/sched5 1> /dev/null
25 * * * * /usr/local/sbin/sched5 1> /dev/null
30 * * * * /usr/local/sbin/sched5 1> /dev/null
35 * * * * /usr/local/sbin/sched5 1> /dev/null
40 * * * * /usr/local/sbin/sched5 1> /dev/null
45 * * * * /usr/local/sbin/sched5 1> /dev/null
50 * * * * /usr/local/sbin/sched5 1> /dev/null
55 * * * * /usr/local/sbin/sched5 1> /dev/null

As can be seen, the script is stored in /usr/local/sbin, in the path for root - as normal users do not need to access it.

The script
The complete script is copied here:


#!/bin/bash
#
# sched5 Check every 5 minutes /etc/sched5.conf
#  for possible jobs to run
#  Needs to be started every 5 minutes from cron
#  Definition of schedules in /etc/sched5.conf
#
# Version: 0.0.1 - Thursday, Jul 23, 2009
#
# Author: Niels Horn (niels.horn@gmail.com)


###################
## Configuration ##
###################

# Standard interval
SCHED5_INTERVAL=5

# Default log
SCHED5_LOG=/var/log/sched5.log

# Default log level:
# 0 = no logging
# 1 = log execution of jobs
# 2 = log everything
SCHED5_LL=1

# Read configuration from /etc/sched5.conf
. /etc/sched5.conf


####################
## Get DAY / TIME ##
####################
DAY=`date +%u`
TIME=`date +%H:%M`
[ $SCHED5_LL -ge 2 ] && \
   echo "Started: Day=$DAY Time=$TIME" >> $SCHED5_LOG


####################################
## Main loop: check all schedules ##
####################################

for sched in `seq $SCHED_NUM`; do

   sched_name=SCHED${sched}_NAME
   eval sched_name=\$$sched_name

   [ $SCHED5_LL -ge 2 ] && \
      echo "-- Schedule $sched = $sched_name" >> $SCHED5_LOG

   # get rules for this schedule
   sched_rules=SCHED${sched}_RULES
   eval sched_rules=\$$sched_rules

   # loop through all rules for this schedule
   cmd_found=0
   for rule in $sched_rules; do

      [ $SCHED5_LL -ge 2 ] && \
         echo "   -- Rule $rule " >> $SCHED5_LOG

      # dissect rule
      rule_day=`echo $rule | cut -f1 -d,`
      rule_tim=`echo $rule | cut -f2 -d,`
      rule_cmd=`echo $rule | cut -f3 -d,`
      # calculate time+interval
      timh=${rule_tim:0:2}
      timm=${rule_tim:3}
      [ "${timm:0:1}" == "0" ] && timm=${timm:1}
      let timm=$timm+$SCHED5_INTERVAL
      [ ${#timm} -eq 1 ] && timm="0"$timm
      tim2=$timh":"$timm

      [ $SCHED5_LL -ge 2 ] && \
         echo "   -- Rule: $rule_day $rule_tim-$tim2 -> $rule_cmd" >> $SCHED5_LOG

      # Check if rule is valid for this day
      if [ "$rule_day" == "*" -o "$rule_day" == "$DAY" ] ; then

         [ $SCHED5_LL -ge 2 ] && \
            echo "      -- day ok" >> $SCHED5_LOG

         # Current time => time of rule?
         if [ "$TIME" == "$rule_tim" -o "$TIME" \> "$rule_tim" ] ; then
    
            [ $SCHED5_LL -ge 2 ] && \
               echo "      -- time start ok" >> $SCHED5_LOG

            # Current time < time of rule + interval?
            if [ "$TIME" \< "$tim2" ] ; then

               [ $SCHED5_LL -ge 2 ] && \
                  echo "      -- time end   ok" >> $SCHED5_LOG
               # ok, we found a command to execute!
               cmd_found=$rule_cmd
            fi
         fi
      fi
   done # all rules for this schedule

   # Did we find a command to execute?
   if [ "$cmd_found" != "0" ] ; then

      [ $SCHED5_LL -ge 2 ] && \
         echo "   -- Starting command $cmd_found" >> $SCHED5_LOG

      # Get command to execute
      cmd=SCHED${sched}_CMD_$cmd_found
      eval cmd=\$$cmd

      [ $SCHED5_LL -ge 1 ] && \
         echo "$TIME Schedule $sched / $sched_name: Starting command \"${cmd}\"" >> $SCHED5_LOG

      # Execute command
      . $cmd

   fi

done # all schedules

[ $SCHED5_LL -ge 2 ] && \
   echo "Finished" >> $SCHED5_LOG

# all done!

Save this script as /usr/local/sbin/sched5 and chmod it to 700, as only root needs to read and execute it. It can also be downloaded from my site.

The configuration file
The configuration file is saved as /etc/sched5.conf and is a simple text file.
To explain to options, I put the examples I gave in the beginning of this post in this configuration:


#!/bin/bash
### Configuration for 'sched5' ##############################################
##
## requires sched5 to be started every 5 minutes from crontab
##

#########################
## Standard Parameters ##
#########################

### Location of log
# Default = /var/log/sched5.log
#SCHED5_LOG=/var/log/sched5.log

### Logging Level
# 0 = log nothing
# 1 = log execution of jobs
# 2 = log everything
# Default = 1
#SCHED5_LL=2


###############
## Schedules ##
###############

# Number of defined schedules
SCHED_NUM=2

##
## Start of Schedule 1 (SCHED1)
## Repeat following lines for each schedule
## Changing the variables from 'SCHED1' to 'SCHED2', 'SCHED3', etc.
##

# Name of schedule, only used in log
SCHED1_NAME=foo_schedule

# Commands to execute
# valid commands are SCHEDx_CMD_1 to SCHEDx_CMD_9
SCHED1_CMD_1='foo start 1234'
SCHED1_CMD_2='foo stop 1234'

# Rules for execution: day,time,cmd
# where day = day to execute (1=Mo,2=Tu,...7=Su, *=all)
#  time = time to execute command
#  cmd = # of command to execute (1-9, 0=do nothing)
# Separate rules with space, later rule has preference over earlier rule,
# so you can start with a general rule for all days (*), then alter for
# specific days (like 7=Sunday)
# Use cmd=0 to cancel a more general rule (like day=*)
SCHED1_RULES="\
*,23:00,1 \
7,23:00,0 \
*,01:00,2"

##
## End of Schedule 1 (SCHED1)
##

SCHED2_NAME=bar_schedule
SCHED2_CMD_1='bar load 1 2 3'
SCHED2_CMD_2='bar load 4'
SCHED2_RULES="\
*,12:00,2 \
3,12:00,1"

Dissecting the configuration file
The first lines define the level of logging and where the log should be saved.
The defaults are explained in the text.

In this example we have two different schedules:


# Number of defined schedules
SCHED_NUM=2

The first schedule has more comments, to explain all options.

First we see the name of the schedule, only used in the log:


# Name of schedule, only used in log
SCHED1_NAME=foo_schedule

Then we'll find the several commands we can schedule:


# Commands to execute
# valid commands are SCHEDx_CMD_1 to SCHEDx_CMD_9
SCHED1_CMD_1='foo start 1234'
SCHED1_CMD_2='foo stop 1234'

All commands must be executable from the command line by root to function.
We can actually have several different commands, and to be exact, names can also end in words, like "SCHED1_CMD_start" - just change the code from "1" to "start" in the rules below.

We now go to the rules of this schedule:


# Rules for execution: day,time,cmd
# where day = day to execute (1=Mo,2=Tu,...7=Su, *=all)
#  time = time to execute command
#  cmd = # of command to execute (1-9, 0=do nothing)
# Separate rules with space, later rule has preference over earlier rule,
# so you can start with a general rule for all days (*), then alter for
# specific days (like 7=Sunday)
# Use cmd=0 to cancel a more general rule (like day=*)
SCHED1_RULES="\
*,23:00,1 \
7,23:00,0 \
*,01:00,2"

As you can see, the special command "0" cancels a previous rule. So in this example, we always run command 1 (foo start 1234) at 23:00h, except on Sundays (day=7).
The second rule is simpler: start command 2 every day at 01:00h.

The second schedule has no comments, to show how simple it is to add extra schedules:


SCHED2_NAME=bar_schedule
SCHED2_CMD_1='bar load 1 2 3'
SCHED2_CMD_2='bar load 4'
SCHED2_RULES="\
*,12:00,2 \
3,12:00,1"

Starting it all
After changing the crontab, saving the script and setting up the configuration, make sure that everything is scheduled by restarting crond:


killall crond
/usr/sbin/crond -l10 >>/var/log/cron 2>&1

This last line comes from /etc/rc.d/rc.M

As the configuration file is re-read every time the script starts, you can just edit the /etc/sched5.conf file and the changes will be in effect immediately.

As always, feel free to comment on this post with questions or suggestions!

Firewall - Blocking a specific IP

2009-07-23T16:46:00.003-03:00

This week I needed a solution to block and unblock certain IPs from accessing the internet at certain times.
I didn't want to change my firewall script too much and didn't want to change it every time the rules changed (which change a lot due to variable circumstances).

So I created a two-part solution. In this post I will describe how I changed my firewall and show a simple script that can block or unblock a specific IP address.

In a following post I will describe how I created a script with a configuration file where I can define when to do what.

iptables and chains
Firewalls in Linux are built with iptables and "chains". Check this article for some basics about writing your own firewall script.

In a chain you can put several rules to filter network packets. It is possible to call a chain from another chain. If the called chain does not filter the packet, it automatically returns to the calling chain.

For instance, we have the standard "FORWARD" chain in a firewall.
In the beginning of this chain, we can always call a user-defined chain called "f_ip".

We create the user-defined chain with:


iptables -N f_ip

And pass all forwarded packets through this chain by including this line as one of our first rules in the FORWARD chain:


iptables -A FORWARD -j f_ip

If the "f_ip" chain is empty, or none of the rules filter the packet to be forwarded, the "FORWARD" chain takes over again:

Now I also want to know if a blocked IP address tried to use the internet, so I created another user-defined chain to log & drop packets:


iptables -N f_ip_drop
iptables -A f_ip_drop -j LOG --log-level 6 --log-prefix "FW: ip: "
iptables -A f_ip_drop -j DROP

Take note that for the time being, nothing goes to the f_ip_drop chain!

But now I can use an external script to add rules to the f_ip chain to filter a specific address without having to change my firewall script.
This external script could contain something like:


iptables -A f_ip -s a.b.c.d -j f_ip_drop

(where "a.b.c.d" is substituted by a real IP address of course)

This part of the firewall then works as follows:

The external script
So now I had my firewall altered and I was ready to write my script to block and unblock specific IP addresses.

The result is here:


#!/bin/bash
#
# fw_ipfilt Filter specific IP addresses
#  Needs rc.firewall 0.2.3 or newer
#
# Version: 0.0.1 - Thursday, Jul 23, 2009
#
# Author: Niels Horn (niels.horn@gmail.com)


###################
## Configuration ##
###################

IPT=iptables


######################
## Clear IP filters ##
######################
ip_clear() {
  # flush f_ip chain
  $IPT -F f_ip
}


######################
## Add IP to filter ##
######################
ip_addip() {
  ip=$1
  # send all packets from or to $ip to f_ip_drop chain
  $IPT -A f_ip -s $ip -j f_ip_drop
  $IPT -A f_ip -d $ip -j f_ip_drop
}


###########################
## Remove IP from filter ##
###########################
ip_delip() {
  ip=$1
  # delete rules for $ip from f_ip chain
  $IPT -D f_ip -s $ip -j f_ip_drop
  $IPT -D f_ip -d $ip -j f_ip_drop
}


###################
## Check Command ##
###################

case "$1" in
  'add')
    ip_addip $2
    ;;
  'clear')
    ip_clear
    ;;
  'del')
    ip_delip $2
    ;;
  *)
    echo "use $0 add|del <ip> or $0 clear"
esac

I saved this script as /usr/local/sbin/fw_ipfilt and made it executable and readable only for root (chmod 700).
Now I can block an IP address at any time with:


fw_ipfilt add 192.168.1.123

and unblock it with>


fw_ipfilt del 192.168.1.123

To unblock all previously blocked addresses use:


fw_ipfilt clear

As always, if you have any questions or suggestions, feel free to comment on this post!

Older Slackware versions (VI)

2009-06-13T12:15:00.003-03:00

Last October I wrote some posts about installing older Slackware versions on VMware. I have since sort of abandoned VMware for several reasons:

It might be free for personal use, but it is not Open software

It is a hassle to keep it functioning with every kernel change

The latest versions need PAM, which can be installed on Slackware, but is not included

There are at least two Free, Open Source alternatives available: VirtualBox and Qemu. Each one has its advantages and disadvantages.

VirtualBox has a nice user-interface and easy to configure options. The open-source version however does not include USB emulation.

Qemu, on the other hand is extremely flexible, can emulate several types of mice, network cards, usb-devices, and is not only a virtualization system but also an emulator for other platforms, like ARM, PowerPC, etc.
But it has no graphical user interface and is complete command-line driven.
This "disadvantage" actually can be an advantage. Sometimes I want to create a simple shortcut that can start a virtual machine without clicking too many buttons.
With Qemu I can create a shell script that starts Qemu with the right parameters and loads my virtual machine with just one click.

But to get back to the original subject...
This week I learned about the fact that an even older version of Slackware was available - Slackware 1.01 ! I actually had read about it some time ago but had forgotten to check it out. I did some research on Google and found out that it can be downloaded from several sites. Since most appeared to be private, non-professional sites, I won't mention them here so that these people won't have bandwidth problems because of me.
But if you're interested, just Google for Slackware 1.01

I decided that it would be a nice compatibility test for Qemu :)
To install a complete version, with X, you'll also need to download a version of the forefather of Slackware, SLS, as the available Slackware 1.01 does not come with the 'X' disks. But the proper Slackware installation script tells us that the SLS disks can be used and those are still readily available on the ibiblio.org ftp site. I used the SLS-1.03 version, as it was released two days before Slackware 1.01 (we're talking about August 1993 here, almost 16 years ago...)

update
After several requests, I decided to put Slackware 1.01 and the X-disks from SLS 1.03 on my site for download:
Slackware 1.01
X-disks from SLS 1.03

So after you downloaded Slackware 1.01 and SLS 1.03, let's start installing our new virtual machine!

But first transform the downloaded folders (A2, A3, A4, etc.) in disk images that can be read by Qemu.
You can do this by creating an empty image with:

mkfs.msdos -C disk_xxx.img 1440

mounting it with:

mount -o loop disk_xxx.img /mnt/floppy

and then copying the files to /mnt/floppy.
In my post about Slackware 1.1.2 I showed a little script to make life easier, but it has to be adapted a bit to work with disk numbers greater than 9. I'll leave that as an exercise to the reader. ;)

1. Preparing the environment
The complete installation of Slackware 1.01 + X + TCL takes up just over 100MB on a hard drive, so I suggest creating a virtual drive of at least 150MB, so that we have some space left to play around.
I created mine with:

$ qemu-img create -f qcow2 slack101.img 200M

Next I created a little shell script to start Qemu with some extra parameters:

#!/bin/bash

# Start qemu w/ sudo, so that allowed users can run emulation
sudo qemu \
  -localtime \
  -m 64M \
  -serial msmouse \
  -vga std \
  -fda disk_a1.img \
  -hda slack101.img \
  -net nic,model=ne2k_isa -net tap,ifname=tap1 \
  &

The Qemu documentation explains all options, but I will enter in some details here:

-m 64M:
  64MB of memory is enough for Slackware 1.01. remember that we're talking 1993 here...
-serial msmouse:
  Qemu by default emulates a PS/2 mouse, but the X included with SLS did not recognize it, so we'll work with a Microsoft Serial Mouse
-fda disk_a1.img:
  This line is to make Qemu boot from the disk image. After installation, you'll need to remove this line!
-net nic,model=ne2k_isa:
  I haven't been able to set up networking yet, but at least the NE2000 ISA adapter was recognized by Slackware 1.01 :)

Before invoking the script, we'll need the location of the Slackware disk images, especially the first one (A1).

2. Starting Qemu
Invoke the script you just saved and you'll see the following screen:

As the instructions say, we can log in as root.
Then we need to create a partition, format it and start the installation script.

3. Partitioning the hard drive
Since this is a virtual machine with 64MB of RAM (a lot for those days), I didn't create a swap partition but just one primary partition the size of our virtual hard drive.

Create the partition with:
fdisk /dev/hda/
and follow the menu...

Then format the new partition as suggested by Patrick with:
mk2efs -c /dev/hda1

4. Start installing!
Now we are ready to start the installation process with:
doinstall /dev/hda1

First it will ask us where to install from - our option is to install from "Floppy Disks".
(Notice that there is even an option to install from tape!)

The second question is interesting:

Since I couldn't find the Slackware X series, I used the disks from SLS.
The prompt gives the option to select "(1 or 2)" but I entered "3" to install TeX as well :)

Now you will be prompted for all the packages. Some are required and will be installed automatically - this was actually one of the improvements Pat made...
You will ave to "insert" all the virtual floppy disks during the installation.
In Qemu you can switch to the command console with "ctrl-alt-2" and type:
change floppy0 <path-to-your-disk-image>
and then just switch back to your installating with "ctrl-alt-1".

After the "A" series, we'll go through the "X" series and finally the "T" series.
Be careful ate after the t3 disk with the following question:

5. Creating a boot disk
After all the disks, you'll see the following prompt:

Change your virtual floppy first in Qemu or you will overwrite your t3 disk!
Then just press enter and the boot disk will be created.

6. Configuration
Now you can configure a modem (which we probably do not have in our virtual machine) and a mouse.

To configure your mouse, first go to the Qemu command screen (ctrl-alt-2) and set our mouse to the emulated Microsoft Serial Mouse we configured in the script that starts Qemu:
info mice
should show something like:

Mouse devices available:
  Mouse #0: QEMU Microsoft Mouse
* Mouse #1: QEMU PS/2 Mouse

We can switch to the Microsoft Mouse with:
mouse_set 0

Now switch back to your installation with ctrl-alt-1 and select "5" (Microsoft Serial Mouse) from this screen:

When it asks for the serial port, just select the first one, as that is where Qemu will emulate your mouse.

Now we are asked about LILO:

Since we are only installing Slackware on this drive, we can simply choose "2" here.

After this, we get back to the prompt telling us we can reboot our system.

Go to the Qemu command screen and eject the floppy disk with:
eject floppy0

Go back to your Linux screen with ctrl-alt-1 and reboot your newly installed Slackware 1.01 with
reboot

7. First boot and post-installation
And we're in Slackware 1.01!

Check if your screen says that NE2000 network card was found (if not, check the script you used to start Qemu).

As you can see, our kernel version is 0.99, patch level 12.
This kernel version, as the one I tested in Slackware 1.1.2 (patch level 15), has a problem that makes our virtual machine take up as much as 100% of CPU time on the host machine (or 50% on a dual-core). This also happens with older Windows versions (Windows 98 and older) in VMware, Qemu, VirtualBox, etc.
It is caused by not using the HLT instruction when there is nothing to do. There are some specific utilities to solve this with Windows in virtual machines, but not for the older Linux kernels. I am not sure when exactly this has been solved in the kernel...

Also note that the hostname of this system is "darkstar", as is still the default in the newest versions. In the modern versions the hostname is set in /etc/rc.M, where "darkstar" is used if no name had been specified during setup.
In Slackware 1.01 it is set in /etc/rc.local

For now, let's login as root - no password is needed.

As was mentioned during the installation (and of course you paid attention to everything that flashed by on your screen ;) ), we need to run a script to set the correct permissions for the sample users:
/etc/sampleuseradd
This is to make sure that "gonzo", "satan" and "snake" can access their home folders and read their mail. Of course, "satan" lives in /home/hell and "snake" lives in /home/pit :D

Feel free to wander around in your new Slackware 1.01 before going to the next step!

8. Configuring X
To use X we will need to do some configuration...

The version of X we installed from the SLS disks - XFree86 1.3 - works a bit different from modern X versions. There were no drivers for video cards - X was compiled for a specific card. SLS supplied two versions, one for SVGA cards and one for monochrome VGA cards.
Qemu can emulate several VGA chipsets, but I could not get any of them to work with this XFree86 server. So I used the monochrome XFree86 server instead.

To change the default server, we need to change a symbolic link, logged in as root:

cd /usr/bin/X11
rm X
ln -s XF86_Mono X

Now, login as the sample user "gonzo" (or use snake or satan if you prefer...).
Simly start X with>
startx
And you're up-and-running!

If, like me, you don't like this "virtual desktop" larger than your vga resolution, you can change this behavior. First copy the standard Xconfig configuration file to your home directory, and make it writable:

cp /usr/lib/X11/Xconfig $HOME/
chmod 644 Xconfig

Then edit this file with your favorite editor (vi & joe are included with Slackware 1.01).
In the section that defines the "vga2" (monochrome) server, change the line for the "Virtual" resolution from "800 600" to "640 480".

Now you can run startx again and play some games:

If I have some time again, I'll try to configure the network. It is quite different compared to the newer versions :)

Another update for Slack/390

2009-05-30T20:25:00.004-03:00

Just a quick note...

xpdf has been updated for Slack/390.
This is a security patch, so update your -current system with SlackPkg without further ado! ;-)

In the mean time: I've been playing around with ARMedslack. I'm just waiting for an opportunity to test it on real hardware, but for the moment I'm running it on the Qemu ARM emulator.

Expect some posts on ARMed slack in the near future...

On partitioning your hard drive...

2009-05-27T21:30:00.000-03:00

As I've been using Linux for over a decade, I am asked a lot of questions about my favorite operating system. I don't consider myself an expert, just an experienced enthusiast :-)

One question that pops up every now and then is about the "ideal" partitioning scheme for Linux.
The short answer is that there is no such thing as an "ideal partitioning scheme". It all depends on so many things, like:
- your hardware
- how you are going to use your system
- your future needs
- etc...

When a new Linux user asks me how to partition his new drive for Linux, I usually say that he should just use two partitions: one for swap and one for the rest. Yes, even with a 500+ GB drive...
Why? Because new users can get into trouble filling up a partition that was created too small and then things stop working.
Sometimes I get funny reactions like: "But I read that it is better to create a partition for /home, another for /usr/local etc...". And some even show expressions of disbelief...

But, since the question keeps coming back, I decided to write how I partition my system.
Like I said - it all depends... So the partitioning for my situation might not apply to yours, but reading through this post you might learn a thing or two.

First of all, I "don't do windows", so you won't read anything about how to double boot between Linux and Microsoft Windows, but basically you can just create an extra primary partition to waste some part of your hard disk and configure your preferred boot loader (Lilo or Grub) to access the alternative.

What follows is "the long answer" on partitioning your hard drive ;)

1. About types of partitions
Partitions come in two types: Primary and Extended. You can have a maximum of 4 partitions on one hard disk. But one of them can be of the "Extended" type, in which you can create several "Logical" partitions.

Remember this when you create your partitions, as you cannot transform a Primary in an Extended partition without backing up all your data, deleting the primary partition, creating the Extended and Logical partitions and then restoring your data.
After you created four Primary partitions, you're done... No way to go back without erasing!

2. The first partition - SWAP
The SWAP partition was originally invented to use as an overflow for your memory needs. If your system needs more memory than it has available, it starts "swapping" unused data from memory to this SWAP area. This was very common in the days when computers had less memory.
For the readers to have an idea: the first systems I worked with had 1 MB of RAM...
The old rule was that the SWAP partition should be twice the amount of RAM in your system.

Nowadays memory is cheap and plentiful in modern systems, so you might think you won't need a SWAP partition.
But don't just skip right now...
First of all, the SWAP partition is also used to 'hibernate' your system if it is capable of doing this (actually, I think *all* systems are capable, but normally only notebooks use this).
Hibernating simply saves all memory to the hard drive and reloads it when you reboot your system.
Guess where the memory is saved? Yes, on the SWAP partition.
So, despite the old rule, it should be at least the size of your RAM.
If you have like 4 GB of RAM, you won't need 8 GB of SWAP space. A SWAP partition of 4.1 GB is good enough.

If you use several Linux flavors on your system, you can have a single SWAP partition for all of them. Just remember you'll loose the 'hibernate' function if you reboot in a different flavor!

The SWAP partition is of the type "82" for those using fdisk under Linux.

3. The second partition - "root"
The "root" partition is the base (or 'root') of the hierarchical file system. It is mounted as "/" in Linux and from there you can go down the hierarchy to any folder or device.
The standard of how this hierarchy is set up is well defined in the Filesystem Hierarchy Standard (or FHS) for all Unix-like operating systems. You can read more on this standard here and here.
Unfortunately, not all Unix or even Linux flavors adhere 100% to the standard, but that's life...

The root partition is where the basic operating system is installed and all files needed to boot your system, get it connected to the network, etc., should be installed here.
Other files, like data, applications not needed for basic operations, user files, etc., can be on other partitions that are mounted later in the boot process.
The "/root" - the 'home' directory of the "root" user must be on the root partition to guarantee that root can login, even if the network is unavailable or external hard drives are not accessible.

Most modern Linux distributions are about 5 to 7 GB in size when fully installed.
To have some extra space, I usually create my root partitions with a size of 15 GB.

4. Extra "root" partitions
Why create extra root partitions? Because you might want to experiment with newer versions of programs, without messing up your working installation.
Or you might want to try out a completely different distribution of Linux for a change.
I personally keep three "root" partitions on my drive, but two should be enough in most setups.
If you make them 15 GB, like your first root partition, you should be ready for most installations.

5. The "/boot" partition
In Linux the /boot folder is used to store the kernel and the 'initrd' files. It is (normally, but do read on...) only used during the boot process.

Most people forget to make a separate partition for /boot. If you run only one installation of Linux on your system, that's fine. But if you plan to setup a multiple-boot system, with more than one Installation of Linux, possibly mixing different flavors, you might get confused when configuring your boot loader.

For instance, let's say you install Slackware and Ubuntu on your system.
From Slackware, you configure your /etc/lilo.conf to read the kernel from /boot/vmlinuz-xxxx
To include Ubuntu in your lilo menu, you would need define your image as /dev/sdxx/boot/vmlinuz-yyyy
And to make things worse, after booting Ubuntu, your /etc/lilo.conf there will have to be different, referring to the Slackware kernel as /dev/sdyy/boot/vmlinux-xxxx

To keep things simple, have a separate /boot partition on your drive that is accessible from all your Linux installations as /boot. Just take care to name your kernels in an organized way, so that you can remember which kernel belongs to which Linux distro.

Now you will still have several copies of your /etc/lilo.conf, as it stays on the root partition of your Linux installations.
I solved this by creating an /etc folder in /boot, where I put the lilo.conf file and then create a symbolic link in /etc with this command:
# ln -s /boot/etc/lilo.conf /etc/lilo.conf
This way I can edit my lilo configuration from any Linux installation and keep things simple.

As for the size of the /boot partition, I make it 250 MB and that has always been enough for me, even with several kernels from several concurrent installations.

6. The (optional) "/home" partition
The /home partition is the subject of many discussions. Each user on a Unix or Linux system has its own /home/<username> folder, accessible only to this user and the all-powerful root.
User-specific configuration files are stored there as well, mostly in hidden sub-folders like .mozilla, .mc, etc.
If your system is only going to have one user, you might as well store everything you want in your "home" folder. But if your system has several users that share files, it is not a good idea to store them here.

The /home partition also can cause problems if one specific user put a lot of files in his home folder, filling up the whole partition and effectively locking the system for other users that can't even save a simple configuration file. The solution to this problem is configuring a quota-system, but that is beyond the scope of this post.

As a simple rule, I create my /home partition with the size of (number of users) x 2 GB. That should be enough to save all configuration files. Shared data (downloaded MP3 files, pictures from digital cameras, etc.) go in a separate partition for data (just continue reading...)

7. The (optional) "/usr/local" partition
As I wrote above, I create my root partitions with the size of 15 GB. This is normally more than enough for a standard Linux installation plus several extra programs.
If you are installing a server with lots of local, non-standard (read: not provided by the standard installation of your Linux distribution) programs, you might want to create a /usr/local partition.

The size of this partition depends on your specific needs.

8. The (optional) "data" partition
Your desktop (or server) might contain data files you want to share with other users - locally or over the network.
I have seen many discussion on where these files should be saved on a Linux system.
Some prefer the "home" folder of the user, but then they will be available only to that particular user (unless you change the standard permissions, which is not a good idea).
Others prefer a special folder in the root directory, like "/data", "/photos", "/mp3", etc. I personally don't like this idea, as it goes against the FHS mentioned before.

In *my* opinion, data should be stored under /srv/xxxx, which is defined by the FHS as "site-specific data which is served by this system".
If you are sharing your pictures or mp3 files, you are "serving specific data" on your system.
So I mount my "data" partition on /srv/data with sub-folders like "pictures", "music", etc.

The size of this partition is limited by your hard drive only and your specific needs.

9. Final conclusions
Do not forget to define all your partitions in your /etc/fstab file to mount them at boot time.

And - I can't say this enough - it all depends on your needs.
You might not need all these partitions. You can very well survive with just a SWAP and a single root partition on a 1 TB drive. You just might encounter some problems when updating your system...

Using SlackPkg on Slack/390

2009-05-02T14:33:00.004-03:00

As promised in my previous post, some instructions to use SlackPkg in Slack/390 to keep your installation up-to-date.

After almost two years without activiry, the maintainers have released some patches / upgrades for Slack/390 - both the -stable and the -current versions.
Since I use SlackPkg on my other Slackware installations (12.1, 12.2 & -current), I wanted to use this same tool in my Slack/390 installation.

First i tried with the version that is included in /extra in Slack/390, but it is quite old (1.4, from 2005) and it simply didn't work.

The first problem is that the big majority of packages on the Slack/390 mirrors do not have the associated xxxx.tgz.asc file, which contain the GPG ckecksum of the package.
This was simple to resolve, setting CHECKGPG=off in /etc/slackpkg/slackpkg.conf

But the second problem I encountered was with the naming of some files on the Slack/390 mirrors that differs from the 'main' Slackware version:

The MANIFEST.bz2 files are called MANIFEST.s390.bz2 in Slack/390

The CHECKSUM.md5 files are called CHECKSUM.s390.md5 in Slack/390

The PACKAGES.TXT files are called PACKAGES.s390.TXT in Slack/390

The FILELIST.TXT file is called FILELIST.TXT.s390 (yes, at the end) in Slack/390

I remembered from the newer versions that there was an option for the 'architecture', so I decided to try SlackPkg 2.70.5 from slackware-12.2
It can be downloaded here or any valid Slackware mirror.
Since SlackPkg is written as a collection of scripts and marked as "noarch", I expected no problems.

So I downloaded the package, upgraded the 1.4 version with upgradepkg and edited /etc/slackpkg/slackpkg.conf
I commented out the 'standard' x86 architecture and uncommented the ARCH=s390 line.
But no luck yet... Still the same problems with the differences in the file names.

At this moment I reached the conclusion that I had to 'hack' the SlackPkg scripts to get it working.

I ended up modifying two files, /usr/bin/slackpkg & /usr/libexec/slackpkg/core-functions.sh

The first patch is to the main slackpkg script and defines a variable 'subARCH' to insert the ".s390" text in the filenames in case the ARCH is s390:


--- slackpkg.orig 2009-04-10 23:44:49.000000000 -0300
+++ /usr/sbin/slackpkg 2009-04-10 23:57:28.000000000 -0300
@@ -40,6 +40,7 @@
 SOURCE=$(grep -e "^\([a-z]\)" $CONF/mirrors)
 . $CONF/slackpkg.conf
 ARCH=${ARCH:-i[3456]86}
+[ "$ARCH" = "s390" ] && subARCH=".s390"
 LOCAL=0
 KERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
 TMPDIR=$(mktemp -p /tmp -d slackpkg.XXXXXX 2>/dev/null || echo "FAILED")

The second patch is to the core-functions script and inserts the $subARCH variable in the filenames:


--- core-functions.sh.orig 2009-04-10 23:53:19.000000000 -0300
+++ /usr/libexec/slackpkg/core-functions.sh 2009-04-11 00:02:49.000000000 -0300
@@ -618,16 +618,16 @@
  #
  echo -e "\t\tList of all files"
  for i in $FIRST $SECOND $THIRD $FOURTH $FIFTH ; do 
-  getfile ${i}/MANIFEST.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
+  getfile ${i}/MANIFEST${subARCH}.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
    DIRS="$DIRS $i"
  done
 
  echo -e "\t\tPackage List"
- getfile FILELIST.TXT $TMPDIR/FILELIST.TXT
+ getfile FILELIST.TXT${subARCH} $TMPDIR/FILELIST.TXT
 
  if [ "$CHECKPKG" = "on" ]; then
   echo -e "\t\tChecksums"
-  getfile CHECKSUMS.md5 ${TMPDIR}/CHECKSUMS.md5
+  getfile CHECKSUMS${subARCH}.md5 ${TMPDIR}/CHECKSUMS.md5
  fi
  cp $TMPDIR/CHECKSUMS.md5 $WORKDIR/CHECKSUMS.md5
   
@@ -635,7 +635,7 @@
  # 
  echo -e "\t\tPackage descriptions"
  for i in $DIRS; do
-  getfile ${i}/PACKAGES.TXT $TMPDIR/${i}-PACKAGES.TXT
+  getfile ${i}/PACKAGES${subARCH}.TXT $TMPDIR/${i}-PACKAGES.TXT
  done
 
  # Format FILELIST.TXT

With these changes, I got SlackPkg working in my Slack/390 installation!

There are still some problems, but they depend on some cleaning up of the Slack/390 mirrors.
In the following image you can see that SlackPkg wants to "upgrade" some packages to older versions:

The fact that SlackPkg want to "downgrade" itself to version 1.4 is understandable, as it is the official version for Slack/390.
The suggestions to downgrade abiword, gftp and gucharmap are caused by the fact that these packages exist two times on the mirrors, once in slackware/gnome (the older versions) and once in slackware/xap (the newer versions).
I wrote about these inconsistencies to s390support@slackware.com but unfortunately have not received any answers yet.

Even with these minor problems, keeping your Slack/390 installation is a lot simpler now with a working SlackPkg!

Update on Slack/390

2009-05-01T19:22:00.002-03:00

For those who have been following my posts on installing Slack/390 on Hercules:
There has been a security update this week - see the ChangeLog

I recently managed to patch a current version of SlackPkg to work on Slack/390 (the version included in /extra does not work).
I'll try to organize my notes during the following days and publish the patch so that everyone can keep Slack/390 updated with this wonderful tool :)

Tux and... Tuz?

2009-04-18T16:45:00.000-03:00

In a previous post I wrote something about our little friend Tux, the symbol of Linux.

On most computers running Linux he'll show up while the kernel is starting up the main services, once for every processor in your system. This little picture in compiled into the kernel and, if you have the sources on your system (like on almost all Slackware installations), you can find him at /usr/src/linux/drivers/video/logo in his various forms (black & white, color, with several architecture-logos, etc.)
The most well-known version is in the logo_linux_clut224.ppm file:

Who likes to use the latest version of the kernel, will have noticed that as of 2.6.29, Tux has been replaced by... Tuz:

Tuz is a little Tasmanian Devil trying to disguise as a penguin :-)

Linus Torvalds had already announced this chance in his blog and as most understood, this is a temporary change, only in the 2.6.29.x kernels.

But for those who can't wait and really do not like Tuz, it is possible to compile your own kernel with Tux on your screen again.

First you'll have to get hold of the original logo_linux_clut224.ppm with the image from Tux. Get it from a system still running the 2.6.28.x kernel or older, or find it on the internet. Save this file in /usr/src/linux/drivers/video/logo/ and then follow these standard steps to compile your kernel:

# cd /usr/src/linux

# make mrproper

Copy the configuration file of your current kernel (usually in /boot) as .config here

# make menuconfig

In the configuration menu, choose "General setup" and change the "Local version" to something like "-tux", so that you can recognize your custom kernel later. Exit the menu saving your change.

# make (this will take a while, depending on your processing power...)

# make modules_install

# cp arch/i386/boot/bzImage /boot/vmlinuz-tux
# cp System.map /boot/System.map-tux

# cp .config /boot/config-tux

If you used an initrd with your normal kernel, you'll need to create one for this custom kernel as well

Add your new kernel to your lilo.conf, run lilo and reboot!

If you feel like it you can also experiment with other pictures... :-)

Lego sculpture of Jesus

2009-04-18T16:11:00.005-03:00

It's been a week since Easter, but here is a little article I found about a sculpture of Jesus, build in a church in Vasteras, Sweden. It was made using 30.000 pieces:

The article can be found here.

Adventures with SlackPkg - Part I

2009-04-18T12:40:00.004-03:00

As a big fan of Slackware, I try to follow the -current branch of this distribution on two of my machines at home.
Doing this is not a good idea on a production machine, as things might stop working. The -current branch is mainly for testing newer versions of packages. The developers of Slackware are usually grateful when receiving feedback if something goes wrong, so that it can be fixed before the new stable release.

I use SlackPkg, a wonderful tool that since long has been included with Slackware as an extra, but since the release of 12.2 is part of the standard installation.
SlackPkg can check for updates to the -current or stable branch and then upgrade or add the available packages and patches.

This week (April 15th) a new version of the 'pkgtools' package was released, fixing some small bugs. While trying to upgrade the package with SlackPkg, it complained that the md5sum was not matching.
After researching some of the code, I found out that in the 'checkpkg' function in /usr/libexec/slackpkg/core-functions.sh the 'MD5ORIGINAL' variable receives the md5sum of both the package to be installed and the source package (source/a/pkgtools/pkgtools-12.34567890-noarch-2.tgz).

A temporary work-around was to disable md5sum checking in SlackPkg, changing CHECKPKG=on to CHECKPKG=off in /etc/slackpkg/slackpkg.conf

I posted the problem at LinuxQuestions and the same day Alan Hicks responded with a patch that basically filters out the source-packages when getting the md5sum.

The trick is in the included 'grep -v'. In /usr/libexec/slackpkg/core-functions.sh the line:
MD5ORIGINAL=$(grep "/${NAMEPKG}$" ${WORKDIR}/CHECKSUMS.md5| cut -f1 -d \ )
was changed to:
MD5ORIGINAL=$(grep "/${NAMEPKG}$" ${WORKDIR}/CHECKSUMS.md5| grep -v '/source/'| cut -f1 -d \ )

It seems to be a rare occurrence of having an installation package and source package with exactly the same name.

The patch lets SlackPkg install the package, but it is still not perfect, as it tries to install it twice.
But I'll leave this to PiterPunk to fix, as it is no serious problem. :-)

KDE Network Configuration tool and Slackware

2008-12-07T10:10:00.004-02:00

This weekend I tried to help someone on LinuxQuestions.org who asked about the knetworkconf tool from KDEs Control Center.
In Slackware this tool hasn't been working for quite some time, it simply says that our operating system is not supported:

(My KDE is in Portuguese, but you'll get the idea...)

I never bothered about it, as I prefer to do all configuring the 'Slackware-way': editing text files. This way I know what's happening and I am in control.

But I understand that this is not for everyone, so this subject pops up once in a while on the forums and I decided to take a look again.

The knetworkconf tool uses several Perl scripts that are stored in /usr/share/apps/knetworkconf/backends
I am definitely not a Perl-guru, but browsing through the several files, I discovered it was nothing too complicated. Basically, network configuration hasn't changed much in Slackware over the last several versions so first I just added the newer version numbers to all files where they were checked.

Posting the first patch file on LinuxQuestions.org a fellow forum member (thanks Woodsman!) discovered that the KDE tool did not show the configured domain correctly.
This actually was a bug in the tool, not my patch, but I managed to solve it.

After some more testing I discovered that every time I saved any changes with knetworkconf, my Samba server stopped working and was even disabled.
This turned out to be another silly bug in knetworkconf, where they forgot to use a variable that holds the current status of Samba.

I posted all patches on the forum and Pat has already included them in the -current branch (see the changelog).
I also sent the patches upstream to the fellows at KDE, so hopefully it makes it into the next versions there as well.

Those who use Slackware 12.1 (the most recent stable version), can copy the following lines and save them in a file:


*** orig/network-conf 2008-12-06 10:17:03.000000000 -0200
--- /usr/share/apps/knetworkconf/backends/network-conf 2008-12-06 10:25:17.000000000 -0200
***************
*** 78,83 ****
--- 78,84 ----
                "vine-3.0", "vine-3.1",
                "ark", 
                "slackware-9.1.0", "slackware-10.0.0", "slackware-10.1.0", "slackware-10.2.0",
+               "slackware-11.0.0", "slackware-12.0.0", "slackware-12.1.0", "slackware-12.2.0",
                "gentoo", "vlos-1.2", "freebsd-5", "freebsd-6");
  
  $description =<<"end_of_description;";
*** orig/network.pl 2008-12-06 10:16:52.000000000 -0200
--- /usr/share/apps/knetworkconf/backends/network.pl 2008-12-06 21:52:53.000000000 -0200
***************
*** 541,546 ****
--- 541,550 ----
         "slackware-10.0.0" => "redhat-6.2",
         "slackware-10.1.0" => "redhat-6.2",
         "slackware-10.2.0" => "redhat-6.2",
+        "slackware-11.0.0" => "redhat-6.2",
+        "slackware-12.0.0" => "redhat-6.2",
+        "slackware-12.1.0" => "redhat-6.2",
+        "slackware-12.2.0" => "redhat-6.2",
         "gentoo"       => "debian-2.2",
         "vlos-1.2"     => "debian-2.2",
         "freebsd-5"    => "debian-2.2",
***************
*** 1855,1860 ****
--- 1859,1868 ----
            "slackware-10.0.0" => \&gst_network_deb22_get_file,
            "slackware-10.1.0" => \&gst_network_deb22_get_file,
            "slackware-10.2.0" => \&gst_network_deb22_get_file,
+           "slackware-11.0.0" => \&gst_network_deb22_get_file,
+           "slackware-12.0.0" => \&gst_network_deb22_get_file,
+           "slackware-12.1.0" => \&gst_network_deb22_get_file,
+           "slackware-12.2.0" => \&gst_network_deb22_get_file,
            "gentoo"       => \&gst_network_deb22_get_file,
            "freebsd-5"    => \&gst_network_deb22_get_file,
            "freebsd-6"    => \&gst_network_deb22_get_file,
***************
*** 3985,3990 ****
--- 3993,4002 ----
            "slackware-10.0.0" => "",
            "slackware-10.1.0" => "",
            "slackware-10.2.0" => "",
+           "slackware-11.0.0" => "",
+           "slackware-12.0.0" => "",
+           "slackware-12.1.0" => "",
+           "slackware-12.2.0" => "",
            "gentoo"       => "",
            "vlos-1.2"     => "",
            "freebsd-5"    => "",
***************
*** 4160,4165 ****
--- 4172,4181 ----
            "slackware-10.0.0" => "slackware-9.1.0",
            "slackware-10.1.0" => "slackware-9.1.0",
            "slackware-10.2.0" => "slackware-9.1.0",
+           "slackware-11.0.0" => "slackware-9.1.0",
+           "slackware-12.0.0" => "slackware-9.1.0",
+           "slackware-12.1.0" => "slackware-9.1.0",
+           "slackware-12.2.0" => "slackware-9.1.0",
            "gentoo"       => "gentoo",
            "vlos-1.2"     => "gentoo",
            "freebsd-5"    => "freebsd-5",
***************
*** 4442,4447 ****
--- 4458,4464 ----
         [ "hostname",      \&gst_parse_fq_hostname, HOSTNAME ],
         [ "nameserver",    \&gst_parse_split_all_unique_hash_comment, RESOLV_CONF,  "nameserver", "[ \t]+" ],
         [ "searchdomain",  \&gst_parse_split_first_array_unique, RESOLV_CONF,  "search", "[ \t]+", "[ \t]+" ],
+        [ "domain",        \&gst_parse_fq_domain,   HOSTNAME ],
         [ "domain",        \&gst_parse_split_first_str,   RESOLV_CONF,  "domain", "[ \t]+" ],
         [ "order",         \&gst_parse_split_first_array, HOST_CONF,    "order", "[ \t]+", ",[ \t]*" ],
         [ "hostmatch",     \&gst_parse_split_first_bool,  HOST_CONF,    "multi", "[ \t]+" ],
***************
*** 4591,4596 ****
--- 4608,4617 ----
            "slackware-10.0.0" => "slackware-9.1.0",
            "slackware-10.1.0" => "slackware-9.1.0",
            "slackware-10.2.0" => "slackware-9.1.0",
+           "slackware-11.0.0" => "slackware-9.1.0",
+           "slackware-12.0.0" => "slackware-9.1.0",
+           "slackware-12.1.0" => "slackware-9.1.0",
+           "slackware-12.2.0" => "slackware-9.1.0",
            "gentoo"       => "gentoo",
            "vlos-1.2"     => "gentoo",
            "freebsd-5"    => "freebsd-5",
***************
*** 5439,5444 ****
--- 5460,5469 ----
            "slackware-10.0.0" => "slackware-9.1.0",
            "slackware-10.1.0" => "slackware-9.1.0",
            "slackware-10.2.0" => "slackware-9.1.0",
+           "slackware-11.0.0" => "slackware-9.1.0",
+           "slackware-12.0.0" => "slackware-9.1.0",
+           "slackware-12.1.0" => "slackware-9.1.0",
+           "slackware-12.2.0" => "slackware-9.1.0",
            "gentoo"       => "gentoo",
            "vlos-1.2"     => "gentoo",
            "freebsd-5"    => "freebsd-5",
***************
*** 5719,5725 ****
         [ "smbdesc",       \&gst_replace_ini,              SMB_CONF,    "global", "server string" ],
         [ "winsserver",    \&gst_replace_ini,              SMB_CONF,    "global", "wins server" ],
         [ "winsuse",       \&gst_replace_ini_bool,         SMB_CONF,    "global", "wins support" ],
!        [ "smbuse",        \&gst_service_bsd_set_status,   "/etc/rc.d/rc.samba" ],
         [ "interface",     \&gst_network_interfaces_set,   OLD_HASH ],
         [ "gateway",       \&gst_network_route_set_default_gw, "%gatewaydev%" ]
        ]
--- 5744,5750 ----
         [ "smbdesc",       \&gst_replace_ini,              SMB_CONF,    "global", "server string" ],
         [ "winsserver",    \&gst_replace_ini,              SMB_CONF,    "global", "wins server" ],
         [ "winsuse",       \&gst_replace_ini_bool,         SMB_CONF,    "global", "wins support" ],
!        [ "smbuse",        \&gst_service_bsd_set_status,   "/etc/rc.d/rc.samba", "%smbuse%" ],
         [ "interface",     \&gst_network_interfaces_set,   OLD_HASH ],
         [ "gateway",       \&gst_network_route_set_default_gw, "%gatewaydev%" ]
        ]
***************
*** 5855,5860 ****
--- 5880,5889 ----
            "slackware-10.0.0" => "slackware-9.1.0",
            "slackware-10.1.0" => "slackware-9.1.0",
            "slackware-10.2.0" => "slackware-9.1.0",
+           "slackware-11.0.0" => "slackware-9.1.0",
+           "slackware-12.0.0" => "slackware-9.1.0",
+           "slackware-12.1.0" => "slackware-9.1.0",
+           "slackware-12.2.0" => "slackware-9.1.0",
            "gentoo"       => "gentoo",
            "vlos-1.2"     => "gentoo",
            "freebsd-5"    => "freebsd-5",
*** orig/platform.pl 2008-12-06 10:17:58.000000000 -0200
--- /usr/share/apps/knetworkconf/backends/platform.pl 2008-12-06 10:35:27.000000000 -0200
***************
*** 90,95 ****
--- 90,99 ----
    "slackware-10.0.0" => "Slackware 10.0.0",
    "slackware-10.1.0" => "Slackware 10.1.0",
    "slackware-10.2.0" => "Slackware 10.2.0",
+   "slackware-11.0.0" => "Slackware 11.0.0",
+   "slackware-12.0.0" => "Slackware 12.0.0",
+   "slackware-12.1.0" => "Slackware 12.1.0",
+   "slackware-12.2.0" => "Slackware 12.2.0",
    "freebsd-4"       => "FreeBSD 4",
    "freebsd-5"       => "FreeBSD 5",
    "freebsd-6"       => "FreeBSD 6",
*** orig/service.pl 2008-12-06 10:16:37.000000000 -0200
--- /usr/share/apps/knetworkconf/backends/service.pl 2008-12-06 10:36:52.000000000 -0200
***************
*** 275,280 ****
--- 275,284 ----
       "slackware-10.0.0" => "slackware-9.1.0",
       "slackware-10.1.0" => "slackware-9.1.0",
       "slackware-10.2.0" => "slackware-9.1.0",
+      "slackware-11.0.0" => "slackware-9.1.0",
+      "slackware-12.0.0" => "slackware-9.1.0",
+      "slackware-12.1.0" => "slackware-9.1.0",
+      "slackware-12.2.0" => "slackware-9.1.0",
  
       "gentoo"         => "gentoo",
       "vlos-1.2"       => "gentoo",

Be careful with the longer lines!
Next, open a console as root and type the following:


cd /usr/share/apps/knetworkconf/backends
patch < (your_saved_patchfile)

This should work with all versions since 11.0, but I only tested it on 12.1 and 12.2-RC1, so all standard disclaimers apply...

The result is a working knetworkconf:

Hercules and Slackware (slack/390) - Part 11

2008-11-22T00:24:00.006-02:00

...Continuing from Part 10

Final configuration and IPLing Slack390

The setup program configured our network, but missed some important details we need to get our network up and running.

1) Loading the network adapter kernel module at boot time

Since we selected to use the LCS we need to load the kernel module that supports it.
This is done by editing the /etc/rc.d/rc.modules file.
I personally prefer VI as an editor, but use whatever you're more familiar with (and is available in our limited 'live'-system).
If you use VI, search for 'lcs' (hint: open the file with 'vi /etc/rc.d/rc.modules' and type '/lcs' + Enter - it's at line 69) and remove the '#' at the beginning of the line that reads:
#/sbin/modprobe lcs
(hint: press 'Home' to go to the beginning of the line, 'd' + 'space' to delete the '#')

Now save the modified file (hint: press ':' + 'wq' + Enter)

2) Setting the options for the lcs kernel module

We also need to tell the lcs kernel module the device number of our emulated LCS.
So we create a /etc/modprobe.conf file with the needed information by typing this line:
echo "options lcs 0xf00,1" > /etc/modprobe.conf

3) Repeating the chandev information from parmfile.txt

To finish, we need to create the /etc/chandev.conf file with the information we put in our original parmfile.txt:
echo "lcs0,0xf00,0xf01" > /etc/chandev.conf

4) Shutdown our system

Now everything is ready to shutdown our running system, so just enter:
halt
and press Enter.

Our telnet session will be closed so we'll change to the Hercules console, where we'll see the following lines:

Now quit from Hercules to guarantee a clean start by typing 'quit' after the Commmand ==> prompt.

5) IPLing our Slack/390 installation for the first time

Start Hercules again and IPL from the first DASD (device number 0120) by typing 'ipl 120' after the Commmand ==> prompt.

Since we selected to start the SSH daemon at boot time, Slack/390 will create three public / private key pairs, one each for rsa1, dsa and rsa.
This will take some time (especially the dsa key pair), depending on your processing power (like 10 to 30 minutes).
You'll see - amongst others - the following lines on the Hercules console:


Starting OpenSSH SSH daemon:  /usr/sbin/sshd
Generating public/private rsa1 key pair.
Generating public/private dsa key pair.
Generating public/private rsa key pair.

This only occurs the first time you IPL your Slack/390. All the other times it will be a lot faster.

The last line on the Hercules console will be:
bash-3.00#

This means that Slack/390 was loaded and is ready to receive connections.

6) Connecting to your Slack/390 system

Now go back to your normal console on your host system.
For security reasons, telnet sessions are not allowed, so we'll have to use ssh from now on.
Connect to your Slack/390 system from your host system (or any other system on your network) with the following command:
ssh root@192.168.1.162

The first time you connect to your new Slack/390 system you'll see the following lines:


The authenticity of host '192.168.1.162 (192.168.1.162)' can't be established.
RSA key fingerprint is df:27:56:56:4b:c3:30:aa:c5:dc:94:2e:21:93:c3:af.
Are you sure you want to continue connecting (yes/no)?

Simply answer 'yes' to continue and you'll see these lines:


Warning: Permanently added '192.168.1.162' (RSA) to the list of known hosts.
root@192.168.1.162's password:

Enter the password for root you defined and you'll get this prompt:


Linux 2.4.29.
root@herc-slack:~#

Congratulations! You finished installing Slack/390 on your (emulated) mainframe!

7) Where to go from here

First of all, create a normal user with 'adduser' so that you don't have to use root to login to your mainframe.

And then? Well, depending on your processing power, there are many fun things to do, like configuring the http daemon to run a webserver on your mainframe, with mysql. Or configure samba, so that you can access it from Windows desktops.

Or start browsing the web with lynx to check for updates of Slack/390:

Oh, but you complain that there are no graphics?
We have graphics on our mainframe! Just enter 'info aalib' and you'll see what I mean:

Hercules and Slackware (slack/390) - Part 10

2008-11-21T22:14:00.003-02:00

...Continuing from Part 9

Configuring our installation

After installing all the selected packages, the setup program takes us to the configuration item of the menu.

1) Kernel parameters

First we can add any necessary boot parameters. Remember that these are roughly equivalent to the parameters you normally put in your /etc/lilo.conf file:

What we define here is:
- where to find our storage devices (dasd=120-121)
- where to find our root partition (root=/dev/dasda1)
- to mount root as read-only first (ro)
- that we won't use an initial RAM disk (noinitrd)

Normally you do not need to change these parameters, so just press Enter here.

2) Select a kernel

We are given a list of possible kernels to boot (roughly equivalent to our menu options in lilo):

Well, we just have one kernel for now, so just press Enter again...

3) Disabling hotplug

We are now asked if we want to enable the hotplug subsystem:

As the text explains, this is very useful for USB and cardbus devices, soundcards, etc. But I haven't seen any mainframe up to now that uses anything like this, so it's better to choose '< No >' here and press Enter.

4) Mouse selection

Now we're asked about the type of mouse on our mainframe:

Again, I still have to find a mainframe with a mouse connected to it, but we have no option to skip this item.
So let's just press Enter to accept the default option.

5) GPM Configuration

The setup program now suggests configuring Slack/390 to load GPM, the console mouse driver:

It is important to select '< No >' here, as loading gpm after booting in Hercules can cause an Oops message and result in an unstable system.
So select No and press Enter.

6) Network configuration

We now go to the step of configuring our network:

Press Enter here to enter the configuration options.

First we'll enter the hostname of our system:

I selected 'herc-slack' but feel free to choose whatever you like.

Next we're asked for the name of our domain:

Use the same name you entered in your 'parmfile.txt'in the beginning.

Now we decide if we want a static or dynamic IP address:

Well, I've never seen a mainframe with a dynamic address, so I selected 'static IP'.

The next item, the IP address, is filled in for us from the step where we configured the network to mount the NFS exported files:

Unless you want to change the IP address for your next boot, just press Enter here.

The netmask is also filled in for us:

Again, press Enter to accept the value.

The address of our gateway is also remembered by the setup program:

Here we also press Enter to accept the proposed value.

Now we get to the part of configuring a name server:

I suggest configuring a nameserver, so that you can access the internet without problems from your mainframe.
Get the address of the nameserver of your ISP or your local network.
Hint: check your local /etc/resolv.conf file

Enter the IP address of your nameserver in the following screen:

I used the IP address of my DSL-modem, which is also a nameserver.
If you're not sure what to fill in right now, don't worry. You can manually change your /etc/resolv.conf file later.

The next screen shows everything we entered and gives us the options to accept our choices, edit a line or start the network configuration all over:

If you're OK with your options, select '< Accept >' and press Enter to go to the next step.

7) Startup services

Now we choose which services we want to run on startup:

I would suggest to deselect 'rc.sendmail' from the list, unless you really want to run mail services on your emulated mainframe.
Remember that you can later select services to start up at boot time by making them executable in /etc/rc.d with the 'chmod +x rc.xxxxxxxx' command.

Select '< OK >' after verifying your options and press Enter.

8) Custom screen fonts

The next question is about custom screen fonts:

But since we'll be accessing our mainframe via ssh sessions, we'll just select '< No >' here.

9) Clock and timezone settings

Now we're asked if the hardware clock of our computer is set to local time or UTC/GMT:

This question is asked to determine how Slack/390 should read the hardware clock when starting up to set the date and time of your system.
When shutting down, Slack/390 tries to update the hardware clock, but Hercules won't let it do so.

Select 'NO' to define the hardware clock as representing local time.
You might have to play around with the TZOFFSET parameter in your hercules.cnf file if things are not the way you expected.

Now we will have to select our timezone:

I live in the south-east of Brazil, so I select 'America/Sao_Paulo', but do select what suits you best.

10) Root password

The setup program detects that we do not have a password for the root account yet, which is never a good idea:

Press Enter to set a password for the system administrator.

We're changing to a text screen to enter the new password:


Changing password for root
Enter the new password (minimum of 5, maximum of 127 characters)
Please use a combination of upper and lower case letters and numbers.
New password:

Enter your password and re-enter it to confirm.

The system will return with the following message:


Password changed.

Press [enter] to continue:

11) Setup is complete... almost...

The following screen shows that setup is complete:

Press Enter to return to the menu and exit the setup program, but do not reboot just yet!

You'll get the following message on your telnet session:


Installation of Slackware Linux is complete.

You may now press ctrl-alt-delete to reboot.

But some essential information is missing, and if you shutdown now, your installation won't start the network we configured.

Next post: Final configuration and IPLing our new installed Slack/390!

Hercules and Slackware (slack/390) - Part 9

2008-11-21T20:10:00.004-02:00

...Continuing from Part 8

Selecting packages to install

We now arrived at the task of deciding exactly which packages we want to install.

1) Package series selection

Slackware (and Slack/390) organizes its packages in 'series'. This comes from the old days, when we installed Slackware from floppy disks.
We are shown a menu with all series that we downloaded, each with a small description:

With the '+' and '-' keys you can scroll through the list and read the last line on your telnet session for more information.

I suggest installing the recommended series and just deselecting the GNOME / KDE and KDEI series if you downloaded them. Select / Deselect a series with 'space'.
You definitely should not deselect the 'A' (Base), 'AP' (Applications), 'L' (Libraries) or 'N' (Networking) series.
Press Enter when you're satisfied with your selection.

2) Prompting mode

Now we have the option how we are going to select individual packages in the series:

I suggest selecting 'full' to avoid problems.
Only select 'expert' is you really are an expert. The problems you might create by skipping an individual package are not worth the space you save. In my experience of over a decade as a Slackware user I have seen too many users selecting individual packages running into problems later on.

Select your option and press Enter to start the installation!

3) Installation

First we'll see a confirmation that the installation has started:

Then every individual package is installed and shown:

4) Sit back and relax

Get some coffee, lunch, dinner, get some sleep...
Because this part of installing all packages may take some hours, depending on your host system, available memory, processing power, network connection etc.

In my case, with the downloaded files on the host computer where Hercules is running, it took some three hours for a full install.

There are some very important steps in the next phase of configuring, so pay attention when the installation of all selected packages is finished.

Next post: Configure your installation!

Hercules and Slackware (slack/390) - Part 8

2008-11-21T18:02:00.010-02:00

...Continuing from Part 7

Selecting the source

Now we need to inform the setup program where it can find the packages to install. The menu gives us the following options:

As explained before, we'll use the option to install from NFS, so select option 2 and the next question is asked:

1) Confirming our local network configuration

The IP address we defined in our 'parmfile.txt' is used as default, so we can just press Enter here and continue with the next question:

Again, the netmask we used in the 'parmfile' is given as a default, so we'll just press Enter again to continue:

In our example we defined a gateway in 'parmfile.txt' so we can choose '< Yes >', but if you do not have a gateway, you can choose '< No >'.

If you choose Yes, you'll have to fill in the address of your gateway:

Press Enter to accept the default from 'parmfile.txt', or type in the IP address of your gateway.

Now that we confirmed our local network configuration, we'll go to the next step.

2) Defining the exported NFS to mount

The first question is the IP address of the server where you saved the packages:

I saved the packages on my host computer, so I'll put its IP address here. Fill in this field with the correct address for your installation and press Enter.

Now we'll have to inform the setup program the exact location of the directory with the packages on the server:

This would be (download)/slackware where you need to substitute '(download)' with the correct path. Be careful to type the path exactly as you defined it in your /etc/exports file.

Press Enter to test is the setup program can mount the exported directory. The result should be something similar to this output:


We'll switch into text mode here so you can see if you have any errors.

Configuring ethernet card...
Configuring your gateway...
Running /sbin/rpc.portmap...
Mounting NFS...

Current mount table:
/dev/ram0 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/pts on /dev/pts type devpts (rw)
/dev/dasda1 on /mnt type ext2 (rw)
/dev/dasdb1 on /mnt/home type ext2 (rw)
192.168.1.110:/var/download/slack390/slackware on /var/log/mount type nfs (ro,nolock,addr=192.168.1.110)

(If you see errors above and the mount table doesn't show your NFS
server, then try setting up NFS again)

Do you need to try setting up NFS again ([y]es, [n]o)?

Check if the last line in the displayed mount table shows your download directory on the NFS server mounted in your emulated mainframe.
If anything went wrong, press 'y' to try other settings.
If all is well, press 'n'.

Next post: Package selection!

Hercules and Slackware (slack/390) - Part 7

2008-11-21T07:07:00.012-02:00

...Continuing from Part 6

Starting setup

After formatting and partitioning our storage, we're ready to enter Slack/390's setup program.
In your telnet session simply enter:
# setup

and the following screen will appear:

Again, experienced Slackware users will recognize this screen from previous installations.

Note
The arrow keys did not work for me via telnet, but you can use the '+', '-' and 'tab' keys to navigate the menu.

You can read the Help section if you like now. It is the original version for Slackware, not adapted for Slack/390, so some details are inaccurate. But most generic info is true for all installations, so if you are not in too much of a hurry, take a look.

We'll skill setting up a swap partition, as we did not create one.

1) Setting up our target partitions

First we have to inform the installer where we want to install Slack/390.
We created two virtual DASDs, and will use them as suggested in the Help section:
- 1 partition / DASD for '/'
- 1 partition / DASD for '/home'

So select 'TARGET' from the menu and you'll get the following screen:

(Yes, I know the size shows up incorrectly, but don't worry about that...)
Select the first available partition (/dev/dasda1) as the target for our root partition.

Now we get the following options for creating a file system on the partition:

Since we're working with virtual devices, a quick format will suffice here, so select 'FORMAT' and we will be shown the following options:

Here we decide which file system to use. Again, we're using a virtual device that's on a real drive of our host system. Using a journaling file system here would cause double journaling. Unless you pretend to save precious data on your mainframe, I suggest using ext2 on your virtual storage to gain some performance.
So choose 'ext2' on this menu and we go to the next point of decision:

Just press Enter for the default inode size of 4096 as suggested, and enjoy the following screen for a while (will take just a minute or two):

After a few moments, we'll see the following menu, giving us the option to select another partition:

As mentioned before, I created a second partition for our '/home' directory, so select the free '/dev/dasdb1' partition now.
Again, select the quick 'FORMAT', the 'ext2' file system and the '4096' inode size.
After formatting our second partition, we are asked where we want to mount it:

Enter '/home' here and press Enter.

We are presented with the lines that setup will put in our /etc/fstab file:

This ends the selection of our target.

Next post: Selecting the source media!

Hercules and Slackware (slack/390) - Part 6

2008-11-21T00:08:00.005-02:00

...Continuing from Part 5

Preparing our DASDs

Before we can install Slack/390 on our local storage, we need to format and partition our devices, just like on a normal desktop.

Remember we created two DASDs and that in GNU/Linux they are called /dev/dasda and /dev/dasdb
The partitions on /dev/dasda will be named /dev/dasda1, /dev/dasda2, etc.

We log in as root in our telnet session and start to work!

1) Formatting DASDs

Slack/390 comes with a special utility to format out DASDs called dasdfmt
Let's format our first device:
# dasdfmt -b 4096 -f /dev/dasda
- -b 4096 defines the block size
- -f /dev/dasda defines our first DASD

When asked if we are sure, answer 'yes'.

After a short pause (after all, our drives are compressed, so there is not much to do), we'll see the following result:


Finished formatting the device.
Rereading the partition table... ok

Repeat the same procedure for our second DASD:
# dasdfmt -b 4096 -f /dev/dasdb

Again, answer with 'yes' and wait for the result.

2) Partitioning DASDs

The partitioning program for DASDs is very similar to fdisk, so experienced Slackware installers should have no problem at all here.

Start the utility with:
# fdasd /dev/dasda

The usual menu comes up:

- type 'n' to create a new partition
- press enter to accept the default starting cylinder
- press enter to accept the default last cylinder
- press 'w' to write the partition table to the DASD and exit

We just created a single partition of the type 'linux' occupying the whole device.

In a real-world situation we would create a swap partition, but since we're on an emulator, this is a bit useless.

Repeat the same procedure for our second DASD:
# fdasd /dev/dasdb
- type 'n' to create a new partition
- press enter to accept the default starting cylinder
- press enter to accept the default last cylinder
- press 'w' to write the partition table to the DASD and exit

Next post: Entering setup!

Hercules and Slackware (slack/390) - Part 5

2008-11-20T22:54:00.008-02:00

...Continuing from Part 4

Getting ready for our first IPL

Yes, we're really almost there :-)

1) Checking the virtual network adapter

There is still one small problem.
Hercules emulates a network adapter, but of course it only exists virtually. In the hercules.cnf file we defined that is uses /dev/net/tun
This is a virtual network tunnel used in many emulators and VPNs.

Check on your host system if you have the /dev/net/tun device. If you don't, you can dynamically load the kernel module for it:
# modprobe tun

Instead of loading it manually after every boot, you can add it to your /etc/rc.d/rc.local script or any other way you prefer.

2) Starting Hercules

Change to your (install) directory and start hercules from the command line:


# cd (install)
# hercules

You'll see the Hercules command console we saw in part 1 of these posts, and if everything worked out fine, you should see these lines:


...
HHCDA020I ./dasd/3390.SLACK.0120 cyls=3339 heads=15 tracks=50085 trklen=56832
HHCDA020I ./dasd/3390.SLACK.0121 cyls=3339 heads=15 tracks=50085 trklen=56832
HHCLC073I 0F00: TAP device tap0 opened
...
Command ==>

The two lines showing the DASDs tell us that both files were found without problems.
The third line shows us that the 'tap' adapter was found as well.

3) IPLing into the kernel

Now we're ready for our first IPL (Initial Program Load, or 'boot' of the mainframe).

At the Hercules 'Command ==>' prompt, type:
ipl c
and Enter.
- ipl is the command to do the Initial Program Load
- c is the device we will load our initial program from (remember we defined 000c as our virtual card reader in hercules.cnf)

A lot of text will scroll by, just as when we boot our Linux desktop.
When the ram disk is loaded, the text will pause while the contents is being uncompressed:

RAMDISK: Compressed image found at block 0

When the network is being configured, you will see this message:


----------------------------------------------------------------------
Starting the Slack/390 S/390 initrd to configure networking, version 0.71
----------------------------------------------------------------------

Afterwards, the network is tested by pinging the local (emulated) adapter, the gateway and the name server.

Then the DASDs are connected and several file system modules are loaded.

If everything works fine, you'll see the following message:

4) Testing the network and connecting through telnet

Open a second console on your host and try to ping your new mainframe:
$ ping -c 3 192.168.1.162

It should respond normally, so let's connect to it with telnet:
$ telnet 192.168.1.162

The result should be:

This is just like booting a Slackware CD or DVD, just a bit different ;-)

Next post: formatting and partitioning our storage...

Hercules and Slackware (slack/390) - Part 4

2008-11-20T21:34:00.004-02:00

...Continuing from Part 3

Defining kernel boot-parameters

OK, so Hercules is configured the way we need.
But to be able to boot the Slack/390 kernel, we need to set some parameters.
It is more or less like setting boot-time parameters in your lilo.conf file, only a bit different :-)

The standard parmfile.txt came with only one (but very important) line:
ramdisk_size=22528 root=/dev/ram0 ro ip=off
This line defines the size of the ram disk and that our root will be found on /dev/ram0 (and mounted read-only)

But just booting the kernel won't get us anywhere. We need an interface to the outside world to install Slack/390 over NFS.

In the (download)/kernels directory we have a file called 'parmfile.values.txt' that explains all options, but to avoid suffering, I'll tell you here how I did it :-)

1) Basic parameters

DASD=120-121
This line tells us where (device numbers again) the DASDs are.

HOST=herc-slack.hn:eth0:192.168.1.162:1500
This line defines our host (actually the guest, as we are working in Hercules, not a real machine):
- herc-slack.hn is our Fully Qualified Domain Name (hostname.domain)
- eth0 is the name of our network interface
- 192.168.1.162 is our ip address
- 1500 is our MTU (Maximum Transfer Unit)

NETWORK=192.168.1.0:255.255.255.0:192.168.1.255:192.168.1.1
Here we define the rest of our network parameters, like we normally do in /etc/rc.d/rc.inet1.conf:
- 192.168.1.0 is our network subnet
- 255.255.255.0 is our network mask
- 192.168.1.255 is our broadcast address
- 192.168.1.1 is our gateway
You will need to adapt these values to your reality...

DNS=192.168.1.110
Speaks for itself... Again, adapt to your reality

SEARCHDNS=hn
The domain name you would normally put in your /etc/resolv.conf as 'search xxx'

2) Defining your network interface

Getting the network to communicate was a bit of a struggle, as the information is not always very clear. But in the end I got it working with these lines:

LCS=0xf00,1
This is the Lan Channel Station we defined in hercules.cnf
- 0xf00 is the device address
- 1 is the type (an OSA-2 adapter in LCS mode)

CHANDEV=noauto;lcs0,0xf00,0xf01
Here we repeat the device addresses of out LCS adapter...

QETHPARM=add_parms,0x04,0xf00,0xf01
And again, just in another format:
- 0x04 stands for channel type LCS

3) Sample parmfile.txt

Again, to save trouble and time, here is an example of a parmfile. Copy the text and save it as (install)/rdr/parmfile.txt, overwriting the downloaded file:


ramdisk_size=22528 root=/dev/ram0 ro ip=off
DASD=120-121
HOST=herc-slack.hn:eth0:192.168.1.162:1500
NETWORK=192.168.1.0:255.255.255.0:192.168.1.255:192.168.1.1
DNS=192.168.1.110
SEARCHDNS=hn
LCS=0xf00,1
CHANDEV=noauto;lcs0,0xf00,0xf01
QETHPARM=add_parms,0x04,0xf00,0xf01

OK, we're finished editing files!
In my next post, we'll do our first IPL into GNU/Linux!

Hercules and Slackware (slack/390) - Part 3

2008-11-20T19:22:00.005-02:00

...Continuing from Part 2

Configuring Hercules

So now we have Hercules installed and working and downloaded everything we need to install Slack/390 on it.

But first we need to configure our mainframe (tell the emulator which devices it needs to emulate, where they are, etc.).

Hercules uses a configuration file named hercules.cnf and looks for it in the directory it started from (but you can override the name and location with the -f option when starting Hercules).

You can find lots of information in the installed documentation (/usr/local/share/hercules/hercconf.html) so I'll just discuss some important details here you need to configure.

1) First we'll define the system parameters:

ARCHMODE ESA/390
Here we define the architecture we will emulate with Hercules. Since we're going to install Slack/390, we'll need the ESA/390 architecture here.

MAINSIZE 256
This defines the 'main storage size' (think of RAM) of your mainframe in MB. I use 256, which is enough for me and doesn't put a high load on my host system. Feel free to change this value depending on your needs and resources.

NUMCPU 1
Here you set the number of virtual CPUs for your emulated mainframe.
For me, one is enough, but you can try two if you like (even on a host with only one physical CPU!). If you need more than two emulated CPUs, you might have to recompile Hercules (see the documentation).

OSTAILOR LINUX
This parameter is just to suppress some unnecessary messages on the Hercules control panel when running GNU/Linux.

PANRATE SLOW
Here we define the refresh rate of the Hercules panel. 'SLOW' means 500 milliseconds, which is fine and reduces the load on the host system. If you define a faster rate here, you can get some funny effects for instance when your file system is checked during boot (the increasing line that shows the completion will scroll like crazy).

2) Now we'll define the hardware we have

In Hercules we configure devices by setting a 'Device number', a 'Device type' (mostly the original model numbers from IBM), and the file name on the host system.

I'll give the lines of a very basic configuration we can use to install Slack/390:

000C   3505   ./rdr/vminstall.image-2.4.26.gcc-3.3.4.img ./rdr/parmfile.txt ./rdr/initrd.gz autopad eof
Note: this is one line in hercules.cnf!
- 000C is the device number
- 3505 is the model number (a card reader)
- then follow a list of the three local file names
- autopad means all lines will be padded up to 80 characters (standard width for punched cards)
- eof signals the end of the 'deck' of cards.
We still need to alter the parmfile.txt... See below...

0120   3390   ./dasd/3390.SLACK.0120
0121   3390   ./dasd/3390.SLACK.0121
You might recognize the device numbers from my previous post, when we created the virtual DASDs. So this is where we define the 'disks' we'll use. GNU/Linux will recognize them as '/dev/dasda' and '/dev/dasdb'.
- 0120 & 0121 are the device numbers
- 3390 is the model number
- ./dasd/3390.SLACK.012[0/1] is the file name on the host

0F00,0F01 LCS   -n /dev/net/tun 192.168.1.162
- 0F00,0F01 are the devices numbers
- LCS stands for Lan Channel Station for Hercules to emulate an Ethernet adapter
- -n /dev/net/tun is the local device that points to your 'tun' adapter
- 192.168.1.162 is the IP address of your mainframe

This is all you need for a minimal Hercules configuration. You can add devices later as needed / wanted.

3) Sample hercules.cnf file
To prevent typing errors, you can copy the following lines and save them as 'hercules.cnf' in the (install) directory:


MAINSIZE  256
NUMCPU    1
OSTAILOR  LINUX
PANRATE   SLOW
ARCHMODE  ESA/390

# reader
000C    3505    ./rdr/vminstall.image-2.4.26.gcc-3.3.4.img ./rdr/parmfile.txt ./rdr/initrd.gz autopad eof

# dasd
0120    3390    ./dasd/3390.SLACK.0120
0121    3390    ./dasd/3390.SLACK.0121

# network
0F00,0F01 LCS -n /dev/net/tun 192.168.1.162

OK, we're getting closer to installing, but we still need to configure the kernel parameters.
See my next post to continue!

Hercules and Slackware (slack/390) - Part 2

2008-11-20T18:00:00.004-02:00

As promised, here are the first steps to get Slack/390 running on your Hercules emulator!

Preparation

0) Get Hercules installed & running
See my previous post if you don't have Hercules yet.

Note
I am a GNU/Linux user, but I know Hercules works under Windows and Mac OS X as well.
If you use one of them, some steps on this page might differ, but I'll leave this up to the reader to find out ;-)

1) Obtain a copy of Slack/390
I got mine from ftp://distro.ibiblio.org/pub but other sources are available.
Check the official Slack/390 site for other links.

Personally I did this installation with the -current version (which is equivalent to Slackware 10.1) but if you prefer the stable version, get 10.0.

To save some time downloading, get only the /kernels and /slackware directories.
From the /slackware directory, you can even skip the gnome, kde and kdei subdirectories, which are large and a bit useless on a terminal-only system.
(ok, it is possible to run KDE or GNOME on Hercules with a X-terminal, but that's too much trouble for me...)

The directory where you downloaded all this, I will call '(download)' from now on.

2) 'Export' the Slack/390 packages
Since we cannot simply insert a CD in our mainframe, we'll install over NFS.
This means that we need to 'export' the directory with the downloaded packages.

I won't write a NFS manual here, since there is enough information available in the man-pages and on the internet, but basically the steps are:
- include the (download)/slackware directory in /etc/exports
- restart NFS with '/etc/rc.d/rc.nfsd restart'

3) Prepare a directory on a file system for your new Slack/390 installation
We'll create some folders with the images to boot our mainframe and the images of our drives where we'll install Slack/390.
A basic installation is about 700MB, but make sure you have some extra space to play around afterwards.
I'll call this base directory (install) from now on.

Create the following directory structure:

$ mkdir (install)/rdr # Here we'll put files for our virtual reader
$ mkdir (install)/ptr # For output of a printer
$ mkdir (install)/dasd # Here we'll put our virtual DASDs (= 'drives')

4) Create two virtual Direct Access Storage Devices
The S/390 works with DASDs - think of hard drives to have an idea.
For our installation, we need to create these drives to have some storage space.

Hercules emulates several models of DASDs, and I selected the 3390-3, which has a capacity of just over 2GB. This is enough for a standard installation (remember we won't use KDE or anything else that takes up a lot of space).
I'll create a second DASD to be mounted as /home, so that we can put any extra stuff there.

A nice feature of Hercules is that is can use compacted DASD images, so that you won't use more than necessary on your host system. My complete installation is under 700MB.

These are the commands to create the two DASDs:

$ cd (install)/dasd
$ dasdinit -z -linux 3390.SLACK.0120 3390-3 SLW120
$ dasdinit -z -linux 3390.SLACK.0121 3390-3 SLW121

Of course, substitute '(install)' with your real path.

- '-z' is to create the 'zipped' or compacted images
- '-linux' is to make sure the DASDs will work under GNU/Linux
- '3390.SLACK.0120' is the name of the file we'll create
- '3390-3' is the model number to emulate
- 'SLW120' if the volume label

For the curious: '120' & '121' are the device numbers we'll configure in Hercules.

5) Prepare the virtual reader for IPL
We'll need to boot a kernel to start installing Slack/390.
On a 'normal' desktop, we'd use a CD, USB-stick, or whatever.
On our mainframe, we'll use the virtual reader.

We'll need to read three files: the kernel, an initial-ram-disk, and a file with some parameters.
Copy the following files from (download)/kernels to (install)/rdr:

- initrd.gz
- parmfile.txt
- vminstall.image-2.4.26.gcc-3.3.4.img

We're ready now to take this to the next level of complexity: editing the configuration files...
See my next post for an explanation and sample files.

Hercules and Slackware (slack/390) - Part 1

2008-11-20T16:57:00.012-02:00

Recently I renewed my interest in the IBM mainframe computers.
From a colleague I learned about a program called Hercules that emulates a complete IBM mainframe system, from the early S/360 to the newer z/Architecture machines.

I already knew that Linux runs on these machines, so I started imagining running Slack/390 (the official S/390 port of Slackware) on Hercules on my Slackware 12.1 box.
Something like this:

|

|

It took a bit more of an effort than expected, since there aren't any simple step-by-step instructions to install Slack/390 on Hercules available on the internet.

So, to help anyone interested, I decided to create this little HOW-TO page...

First a little guide to get Hercules working on your system:

UPDATE: You can now download pre-built Slackware packages for Hercules, see this post.

1) Go to your favorite sources directory (in my case ~/sources):
# cd ~/sources
2) Download the latest version from the Hercules site (use any downloader you prefer, I use wget):
# wget http://www.hercules-390.org/hercules-3.05.tar.gz
3) untar the package:
# tar -xzvf hercules-3.05.tar.gz
4) Go into the directory containing the sources:
# cd hercules-3.05
5) Check if we have all the right version (compiler, etc.):
# ./util/cvslvlck
6) Answer y when asked, logout & login again
7) Configure, compile & install:

# ./configure
# make
# make install

8) Test Hercules to see if it starts ok:
# hercules

If everything worked out fine, you should get a screen like this:

In my next post I'll explain how I installed Slack/390...

VMware-server 1.0.7 on 2.6.27 kernels

2008-11-09T13:23:00.002-02:00

Last Friday lots up upgrades were released for Slackware-current, including a new kernel, 2.6.27.5
Since changing a kernel usually has some consequences, I waited until today, Sunday, to apply all upgrades.
As anticipated, my VMware-server stopped working. Normally I run the /usr/bin/vmware-config.pl script to reconfigure VMware and recompile the needed modules for the new kernel.
But this time I had no success.

So this is where the fun starts!

I started searching several sites (Google really helps) and discovered that the problem is caused by the fact that VMware-server 1.0.7 still uses the "kernel_thread" feature that has been marked for removal since August 2006 (see your /usr/src/linux/Documentation/feature-removal-schedule.txt file). It had finally been dropped in the 2.6.27 kernel.

But, since the 2.6.27 kernel has been out in the open for a while, I started looking for patched and found one in the Ubuntu community, written by a guy called Kang.
It was originally written for VMware 5.5 but works flawlessly on VMware-server 1.0.7 too.

Simply download the patch from Kang's page, untar it and run the runme.pl script (as root):

wget http://www.insecure.ws/warehouse/vmware-update-2.6.27-5.5.7-2.tar.gz
tar -xzvf vmware-update-2.6.27-5.5.7-2.tar.gz
cd vmware-update-2.6.27-5.5.7-2
perl runme.pl

After this, your VMware-server should run fine again!

Slackware/Linux/Unix (pre-)history (Part 3: Unix-wars, and peace)

2008-10-20T22:04:00.004-02:00

The big split

The first versions of Bell Labs' Unix. also known as 'Research Unix', included the full source code, allowing universities to improve and extend the operating system. As I wrote in the previous post in this series, UCB did a lot to add to Unix and created its own distribution - BSD.
The first version - 1BSD - was more like a set of add-ons and patches compiled by Bill Joy. Bit by bit, BSD became larger and larger, with every release coming closer to be a complete operating system.
Bill Joy, who started BSD and later co-founded SUN
In 1981 AT&T started selling commercial licenses of Unix, largely based on version 7 of Unix from Bell Labs, and called it System III. After including some of the BSD additions, like vi and curses, it released System V - Release 1 in 1983.
These two branches, BSD and System V, were incompatible.

Bill Joy founded SUN in 1983 with three graduate students from Stanford University who all had worked on the Stanford University Network, one of the four original ARPAnet nodes. They developed the SUN workstations running SunOS, based on BSD.

While the BSD-based versions dominated the workstation market, several new commercial versions were developed for the server market based on System V, like IBM's AIX and HP's HP-UX.

Attempts to standardize

Several attempts were made to create standards:

In 1983 a Unix users group called UniForum published the Uniforum Draft Standard, UDS83. It was based on AT&T's System III and 4.1BSD. But shortly after 4.2BSD was released with many new features (including TCP/IP) creating several incompatibilities.
In 1985 AT&T released the System V Interface Definition (SVID), formally describing the SysVr2 API and including UDS84. SVID3, following SysVr4, became the basis for IEEE's POSIX standard, tipping the balance more in AT&T's direction than in BSD's.
A consortium of Unix vendors formed X/Open in 1984 and developed the X/Open Portability Guides (XPG), describing a subset of features compatible with all Unixes.

Peace

In 1993 the war finally ended with seventy-five vendors of hardware and software declaring support for X/Open. With this deal, the X/Open consortium acquired the rights to the Unix trademark and created the Single Unix Specification version 1.
In 1999 X/Open absorbed all activities related to the POSIX standard.

Slackware/Linux/Unix (pre-)history (Part 2: A new language, a philosophy, and the spreading of Unix)

2008-10-20T12:24:00.009-02:00

Needing a new language

The first crude version of Unix was written in assembler language on the PDP-7 and later the PDP-11. But Ken Thompson thought it should be written in a higher-level language. In 1971 he first experimented with Fortran, but according to some stories, he gave up after only one day. He then decided to write his own language, loosely based on BCPL, and called it simply B. But B was interpreted so it was too slow for an operating system. B also lacked types, which complicated things.
Ritchie first expanded B, adding types to the language, and named the result New B, or NB. The next step was writing a compiler, which took longer than expected. The result was the C language and Thompson started to rewrite Unix in it, which he finished in 1973.
With this Thompson and Ritchie created a much more portable operating system, leaving only small parts of the code machine-dependent.

The Unix Philosophy

Douglas McIlroy, head of Bell Labs' Computing Techniques Research Department, had created the concept of 'pipes' - chaining processes by streams, or: the output of one program becomes the input of another. His idea was to have specific tools to do specific jobs, and chain small tools together to do more complicated jobs. This was probably the first idea for "software componentry". He summarized this as follows:
- Write programs that do one thing and do it well
- Write programs to work together
- Write programs to handle text streams, because that is a universal interface
This ultimately became known as "The Unix Philosophy".

M. Douglas McIlroy
So the idea was there, but a syntax was needed to use it. Then Brian Kernighan came up with the vertical bar (|) and pipes were born, which led the way to creating several tools with specific tasks.
In the process, McIlroy developed several Unix tools like diff, spell, tr, and others.

A simple (and well-known) example of chaining two programs is:
echo "IBM 9000" | tr A-Z ZA-Y
Where the first part outputs the text "IBM 9000", which goes as input to tr, which shifts all letters (A-Z) one position and forms the name of a computer from a famous movie (ok, I like Sci-Fi movies...).

Spreading of Unix

Unix was a fact now and AT&T started distributing licenses to universities and the government. In 1976 / 1977 Thompson took a six-month leave from Bell Labs to teach at UCB. And of course he taught Unix. After he left, professors and students improved some parts of Unix, creating what became the Berkeley Software Distribution, or BSD, which was resold to several other universities.
UCB established the Computer Systems Research Group (CSRG), which received a grant from DARPA. They made the TCP/IP protocol available for Unix, opening the way for this operating system to play a key role in the early days of the internet.

The following BSD releases contributed several new tools to Unix, like a visual editor (that became vi), the c-shell, delivermail (which became sendmail) and the curses library, the forefather of ncurses.

For the VAX computer BSD included Virtual Memory Management. The kernel image of this Unix version was named vmunix - a name we can recognize in modern Linux kernels, normally named vmlinuz (the final 'z' because if the zlib-compression).

It is estimated that by 1978, over 600 (!) machines were running Unix.

To be continued...

Hidden name in the Linux logo

2008-10-19T11:18:00.006-02:00

This is what makes computing fun - you learn something new every day.

Today there was a post on LinuxQuestions.org by w1k0, who reported something strange with the Linux logo on his ThinkPad T60. The colors were all wrong (Tux had a green belly, blue background) and... to the left-side there was an inscription saying "Simon".

I suggested checking the vga-setting in lilo, but was intrigued by this mysterious inscription.
I am familiar with the history of the Linux logo created by Larry Ewing and the vectorized version by Simon Budig, so I thought of the possibility of a hidden text in the bitmap.

I opened the logo (the standard 224-color version is called logo_linux_clut224.ppm), which can normally be found in /usr/src/linux/drivers/video/logo/, in the gimp.

And I found nothing. So I already started thinking that someone was pulling a joke on w1k0 and had messed with his kernel. But that seemed weird... This someone would have to compile a new kernel, just to get a green-bellied penguin with the name Simon at boot-time.

Then I thought of steganography and how this inscription could be hidden. Since it showed up (with the wrong color) on w1k0's screen, it must be of a color almost equal to the background.

So I opened the logo in the gimp again, clicked on the color-selection tool and changed the 'limit'-setting to 0,0. Then I clicked on a random spot on the black background and Bingo!
There really is a hidden inscription in the Linux logo!

To make it visible, I painted the pixels red and enlarged the bitmap.
The result is here, but do check it out on your own file!

Tux with the "Simon" inscription painted in red

Slackware/Linux/Unix (pre-)history (Part 1: The origins)

2008-10-16T22:45:00.006-03:00

In the beginning there was...

CTSS, the Compatible Time-Sharing System, developed at the Massachusetts Institute of Technology (MIT) Computation Center and first demonstrated in 1961. It had some interesting features like:

inter-user messaging (what we would call 'e-mail' nowadays)
a program called RUNCOM, that could execute several commands put together in a file - like modern-day shell scripts
RUNOFF, probably the first text-formatting software

In 1964 MIT, together with Bell Labs an General Electric (GE) started developing Multics (Multiplexed Information and Computing Service) . GE manufactured mainframe computers in those days for which they needed an Operating System. It was conceived as a modular system, where new resources (memory, disk storage) could be added as necessary. Every file had an Access Control List to share or secure its contents amongst users.
Some novelties of Multics, now considered normal, were:

dynamic linking
daemons
a hierarchical file system
symbolic links

In 1969 AT&T / Bell Labs decided to leave the project and in 1970 GE's computer business was sold to Honeywell.

A Honeywell H6180 at the MIT Information Processing Center

In Europe Multics was distributed by Groupe Bull, where I had my first contact with computers. I don't remember what year this happened, probably around 1975.

The birth of UNIX

Ken Thompson, who had worked through Bell Labs on Multics, had written a computer game called Space Travel for this operating system. Unsatisfied with the performance, he rewrote the program in assembly language for a Digital Equipment Corporation PDP-7, with help from Dennis Ritchie.

Ken Thompson and Dennis Ritchie

Together they teamed up with several other developers to write an operating system for the PDP-7. It is obvious that they were influenced my Multics, but they focused on the philosophy of Keep It Small & Simple, what ultimately became part of the famous Unix Philosophy.
They developed a new file system, a command line interpreter (CLI) and several utility programs for their new OS.
Brian Kernighan, who later co-wrote the first book on the C programming language with Dennis Ritchie, invented the name Unics, as a pun on Multics. According to some stories, after hearing too many comments about "Eunuchs", the spelling was changed to Unix.
On the PDP-7 it eventually supported two simultaneous users.

To get financial support from Bell Labs, Thompson and Ritchie promised to add support for text-processing in Unix. They received a PDP-11 machine to continue their work and write roff and a text-editor. roff was based on the runoff text-formatter from Multics and before that CTSS, and survives until today as the GNU version groff.
In 1971 The UNIX Programmer's Manual was published using troff, an evolution of roff for typesetters.

Thomson & Ritchie working on the PDP-11
To be continued...

Lego Sculpture - You are the model!

2008-10-16T07:14:00.004-03:00

I am a big fan of Lego. Unfortunately I haven't had much time lately to build anything, but I try to keep up-to-date with the latest news.
Yesterday I read that famous department store Neiman Marcus has a new item in it's Christmas Catalog: A life-size sculpture of you made from Lego.

Price-tag: $60,000.00 (does not include shipping). Care to order? Look here.

The artist responsible for sculpting is Nathan Sawaya. Check out his site for some incredible works!

Slackware/Linux/Unix (pre-)history (Part 0: Introduction)

2008-10-15T23:37:00.004-03:00

For some time I've been reading texts on the history of Slackware, Linux, UNIX, etc. It all started with this old Slackware version I found and my quest to get this (and several older) versions working in a Virtual Machine on my modern desktop.

I've been using virtualization and emulation for several years, both professionally and for fun.
Searching for even older versions of Slackware and Linux, I found several articles about the history of Slackware, Linux, GNU, Minix, Unix and so forth and started to collect links and making notes to read more.

This collection of notes just continued growing and growing, as part of this history has parallels with my own history in computing. So I decided to write a series of posts about all this, trying to organize my notes in a chronological way. I have no idea how many chapters / parts / posts there will be, as I am still organizing things. Nor do I know how long it will take to finish. It is all really ad-hoc writing.

Talking about all this with my wife she said it might even become a book. Well, she's the one with a talent for writing, but hey, who knows.
After all, I always used this old saying from José Martí (*), that every man ought to do three things before he dies:

Plant a tree
Write a book
Have a son

I already planted a tree and have a son (a daughter as well). But all I wrote until now are software manuals, and I am afraid that doesn't count.

I have no idea if José Martí really ever wrote or said this. I also heard people quoting Ernest Hemingway saying this, but he lived in Cuba for a while, so he might have picked it up there.

(*) José Martí (José Julián Martí Pérez) was a Cuban journalist / diplomat who fought for the independence of Cuba and is considered a national hero there. When I visited Cuba in 1986 I noticed how people still like him.

The national airport of Havana is named after him and he wrote the verses for the famous song "Guantanamera", that in a way might have something to do with me writing these lines:

Yo soy un hombre sincero
De donde crece la palma
Y antes de morirme quiero
Echar mis versos del alma.

which roughly translates to:

I am an an honest man
From where the palm tree grows,
(well, I do live in Brazil now...)
And I want, before I die,
to cast these verses from my soul
(now I just hope someone will read all this ;-)

My next post will / should be about the origins of it all: UNIX (but I'll start even before that... UNICS)

To be continued!

Older Slackware versions (V)

2008-10-14T22:10:00.001-03:00

Well, I finally managed to get a higher resolution in VMware, at least with Slackware 4.0
I discovered that VMware-server 1.0.7 still includes the drivers for XFree86 3.* & 4.*

In XFree86 3.* there is a separate "server" for each type of interface: one for monochrome cards (who remembers Hercules?), one for simple VGA, one for SVGA, etc...
And VMware supplies a "server" for virtual machines!

I tried the XF86_VMware server on Slackware 4.0, together with the sample XF86Config file.
I just had to change the configuration for the gpm-repeater mouse, include the 800x600 and 1024x768 resolutions and it worked fine in a couple of minutes!

Here is a screenshot of the result, in 1024x768:

As you can see, Netscape now works fine, at least with the not-so-sofisticated sites.
I tried to open linuxquestions.org, but had no success. Simply too many java scripts for good old Netscape 4.51

For now, this VMware driver is just working in Slackware 4.0 No luck so far in Slackware 3.5, although it uses Xfree86 3.* as well.

Older Slackware versions (IV)

2008-10-14T07:42:00.007-03:00

Working with fvwm2 wasn't too much fun... So I started looking for and old Slackware version that had KDE.
I found out that my oldest CD with KDE was Slackware 4.0:

As it says on the cover, it comes with KDE 1.1, so this was my new project.
According to the cover from the original 4-disc box, we're talking June 1999 now.
This is when Tux started smoking a pipe (he was not smoking on the previous Slackware boxes I have). I also have the impression he gained some weight since the previous version.
Well, I guess this is when Tux became a real Slacker...

Installing it, after my experiences with 3.5 & 1.1.2, was simple and fast.
I configured XF86Config in /etc, as in 3.5, and fired up X. The result is here:

Slackware 4.0 was the version I used most. The previous versions were interesting experiences and taught me a lot, struggling to find out how to configure things, etc. After 3.1, 3.4, 3.5 and 3.6 this was the first version I really enjoyed as an operating system, not as some kind of a science project. This is where I started feeling that I was "in control".
I still have 4.0 running on a 486 notebook, after all those years...

Older Slackware versions (III)

2008-10-12T11:22:00.006-03:00

After successfully installing Slackware 3.5 and discovering that Slackware 1.1.2 was still available on the internet at sunsite.unc.edu I simply had to try it...

At first I had no luck, as this version does not support the standard VMware network card (PCnet32) and also lacks support for IDE CDRom drives. The VMware emulated SCSI cards (BusLogic & LSI) were also not recognized.
So the only way would be to install from floppies, just like the old days.

Since I haven't used my internal 3.5" drive in years and didn't feel like formatting 50+ disks, I first gave up.
But then I remembered that VMware also accepts disk-images for floppies, so I wrote a quick-and-dirty script to create all the needed images from the downloaded directories:


#!/bin/bash

for dsk in *[1-9]/ ; do
   length=${#dsk}
   dsk=${dsk:0:($length-1)}
   echo -n "$dsk..."
   cp disk_empty.img disk_$dsk.img
   mount -t msdos -o loop disk_$dsk.img /mnt/floppy
   cp $dsk/* /mnt/floppy/
   umount /mnt/floppy
   echo " [ok]"
done

It gives an error trying to create a disk image from the libc444 folder, but you can ignore that.

Installation was straight-forward and after a lot of virtual disk-swapping, I had my Slackware 1.1.2 installation working.

Here is a first screenshot (look at the kernel version!):

And here you can see how this version is really easy on your memory (less than 4M!) and hard disk:

Configuring X

Now I had to get X working as well...
X looks for a Xconfig file in /etc (for all users) or in your home directory if you need separate configurations per user.
A sample configuration file can be found in /var/X11/lib/X11 so I copied it to /etc and started experimenting.

VMware emulates a standard VGA adapter (no SVGA) so we are limited to 640x480.
I added this line near the end of Xconfig in the "ModeDB" for a standard VGA screen:
"640x480" 25 640 672 768 800 480 490 492 525
In the VGA16 section I changed the Virtual values to 640 480

So now I had a working X, but no mouse...
So, back to reading more man-pages, and I changed my mouse settings in Xconfig to:
ps2 "/dev/bmouseps2"
and X is working!

Here is another screenshot, showing the standard fvwm window manager:

As you can see, we have nine (!) virtual desktops here.

One thing I noticed with this 1.1.2 version, is that it is much slower than the 3.5 version. It also puts a big load on the processor of my host-machine, that goes to 99%. Running 3.5 has almost no effect, it's really easy on the CPU.
This probably has something to do with the 0.99 kernel.

Older Slackware versions (II)

2008-10-11T12:55:00.005-03:00

Finally got X working on my Slackware 3.5 installation.
Well, not perfectly, but good enough to capture a screen:

I had to configure X by editing XF86Config that's stored in /etc in this version.
After some tweaking I got it to work with the basic "generic vga" driver, with a resolution of 640x480. It should work with higher resolutions, but I guess I need something better than vga for this.
If I succeed, I'll post the secret here :-)

For now I'm using the fvwm2 window manager.
As you can see, the system is still running fine, using only about 14M of memory.

I couldn't get Netscape to work, as it tries to open www.netscape.com, which points to aol, which tries to start a load of Java scripts that Netscape can't process...

To be continued...

Older Slackware versions (I)

2008-10-10T21:57:00.008-03:00

Last week I found the original Slackware 3.5 CDs that I have. I have several older versions of Slackware in my collection, most of them original CDs.
I started using Slackware in 1996, when I bought a book called "Slackware Linux Unleashed" from Sams. It included Slackware 96, which is also known as Slackware 3.1

Since I liked Slackware a lot, I bought a subscription to receive the newer versions from Walnut Creek, a company that has ceased to exist.
So somewhere I have the original 3.1 disk and several versions up to at least 4.0
At some point in time the economy in Brazil went berserk and I had to cancel my subscription, since the value of the US$ quadruplicated and I had to fall back to downloading from the internet.
After I met some of the wonderful guys of the Slackware team in person recently (Eric, Robby, Allan) I decided to get a new subscription though.

But, getting back to the point...

Finding this old box of CDs brought back some memories. Memories how I struggled in the beginning to get everything working... and how I learned so much from the experience. It has been and still is wonderful to encounter a problem, search around and in the end be proud to find a solution.
So I started wondering if this version would still work on modern hardware.
I still have a lot of old hardware stacked up here (and when I say old, I'm talking about boards with the Z80 CPU, XT PCs, 286, 386, etc...), but now I install most systems on virtual machines. Yes, I like VMware...
I already have a VM running DOS 3.3, one running Windows 1.01 and another running MINIX. So, the logical next step was to create a VM running Slackware 3.5

I really had no idea if it would work, but I decided to try. In VMware I created a minimal machine with 64MB of memory and a 500MB hard disk. And then I started installing...

This 3.5 version has a bootable CD so it was quite simple.
For those used to recent installs of Slackware it's an easy job. Not much has changed since 3.5 in the interface, so installing this old version was simple.
The only big difference I noticed was that I didn't get an option for DHCP. Maybe in 1997 this was not too common. So I entered a fixed IP address for my local network and continued.

In the end, everything worked fine, except one thing: the network card. VMware emulates a PCnet32 interface, which is not automatically loaded by Slackware 3.5 The solution was simple, as the pcnet32 module exists in Slackware 3.5: just added


/sbin/modprobe pcnet32

to /etc/rc.d/rc.modules and it worked fine.

So I proved it was possible to install Slackware 3.5 (from September 9, 1998) on a Virtual Machine without too much trouble.

Some screenshots to show the result:

First the old-style lilo menu:

And here after logging in, showing the kernel version (2.0.34):

To check the internet connection, let's see if there are some updates in -current with lynx:

And last, just to show the size of Slackware 3.5:

Next chapter:
Adventures to get X working

VMware & Slackware as guest

2008-10-05T13:08:00.005-03:00

Just a quick hint for those having trouble using the 'generic' kernel (as we should always use) when installing Slackware as a guest with VMware.

VMware creates SCSI drives by default when we create a new virtual machine for Linux with a 2.6 kernel, emulating a LSI Logic SCSI controller. The 'huge' kernel that comes with Slackware recognizes this controller as it is built in. But when we try to use the 'generic' kernel it ends up not completing the boot process as it cannot mount the root partition. We are presented with a basic shell to try to solve the problem but we only and up with a 'kernel panic'

You probably already created a initrd.gz (initial RAM disk) to load the modules for your file system with your generic kernel.
To use the LSI Logic controller, we need to add some more modules to the list, like this:


mkinitrd -c -k xxx -m jbd:ext3:scsi_transport_spi:mptbase:mptscsih:mptspi -f ext3 -r /dev/yyy

Replace 'xxx' with your kernel version (I use 2.6.24.7-smp) and yyy with the partition of your root (probably sda1 or sda2).

Don't forget to run lilo again and then you can boot using the generic kernel without problems!

Keeping your clock accurate

2008-10-03T20:40:00.000-03:00

If you want to be sure that your computer clock is accurate - always - you can configure your system to use NTP (Network Time Protocol).

NTP is one of the oldest protocols on the internet and its predecessors, going back to the early eighties. If you are interested in reading a small article about the history of NTP, I recommend this text in PDF. The official 'home' of NTP is www.ntp.org

You can use NTP on your Linux desktop to automatically synchronize its clock to a pool of servers around the world that are official 'timekeepers'. Usually you configure NTP to talk to about three different servers to guarantee that at least one is available at any time. It is best to choose servers near you, so that response times are shorter, which results in a more accurate clock on your computer. There are more than 1.500 servers to choose from, but some areas on our planet are better served than others. For instance: there are almost a thousand servers in Europe, but only 19 in South America (where I live).

Your first step should be to select three servers close to you - preferably in your country, or if there aren't enough, in your 'zone.
Go to www.pool.ntp.org and browse through the tree of zones and servers to select which ones are best for you.
The 'pooling' system automatically translates the addresses to the actual domain- and server names.
For instance, I use: 0.br.pool.ntp.org, 1.br.pool.ntp.org and 2.br.pool.ntp.org and these names are usually translated to servers at local universities or government institutions.
Don't worry about this part, the pooling system takes care of it.

Now that you have selected your servers, let's start configuring your system. As always, I'll use Slackware as an example, but things will be similar in other distributions.

1. Configure /etc/ntp.conf
Edit this file with your favorite text-editor (I use vi) and go to the lines that say:


server <example-server-name>

and replace this line or lines with your servers. In my case, I put:


server 0.br.pool.ntp.org
server 1.br.pool.ntp.org
server 2.br.pool.ntp.org

While we're editing the configuration, let's make NTP a bit more secure, inserting some restrictions. Find the lines (usually at the end) that start with "restrict ...." and replace them with the following:


restrict default nomodify
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer

The address 127.0.0.1 is our local IP address that has no restrictions.
The network / mask combination in the third line is my local network, so that my other desktops can use my system as a time-server, preventing all of them to send NTP queries to the internet.
On the rest of my desktops I put the line "server 192.168.1.1" (my local IP) in their ntp.conf

2. Synchronize your clock manually
If your clock is too much behind or ahead, NTP might refuse to synchronize it, so let's force the first synchronization with a simple command:


ntpdate 0.br.pool.ntp.org

Of course, you should substitute the server name with one from your list.

3. Make your ntp daemon executable
In Slackware this is done with the following command:


chmod +x /etc/rc.d/rc.ntpd

This (again, in Slackware) will make it start every time you boot up your system.

4. Start NTP now without rebooting
Again, a simple command:


/etc/rc.d/rc.ntpd start

That's it!
After a few minutes, check if NTP is communicating with the server pool by running this command:


ntpq -p

It should show the servers it is talking to and one of them should have an '*' in front of it.

Pop-up Dialog in Shell scripts

2008-09-29T15:46:00.005-03:00

As I am an old-time computer user, I still prefer doing almost everything from the command line (CLI). I program almost everything in bash-scripts and schedule them with cron.
But of course I do use a graphical interface to read mail (although I have Alpine configured to read my mail from the CLI) and browse the internet (but I also use links a lot!).
Sometimes a bash script needs to give or get feedback, like reporting an error or just telling everything worked fine. Scheduled scripts normally write logs that can be checked later, or can even send e-mails to a user.
There is another, not so well-known option for interaction with the user, if you use KDE as your desktop environment: kdialog
It has many different options to choose from, so I'll give just a few simple examples:

kdialog --title "Hey you..." --yesno "Do you like this popup?"

This pops up the following dialog:

(You'll just have to believe that "Sim" = "Yes" and "Não" = "No" in Portuguese)
The result of which button the user clicked can be obtained by reading the '$?' variable in bash: '0' for the first button (Yes), '1' for the second ('No') and so on.

Another useful example is:

kdialog --title "Warning..." --warningyesno "Low on space on /var - Continue?"

which gives this result:

There are many more options to show radio buttons, check boxes, prompts for passwords, etc.

Now let's use this in a small script:

#!/bin/bash
#
# Sample on how to use kdialog

ERR_SPACE=101

# Calculate needed space
needed=1000 # ok, we're not calculating...

# Calculate space on $dev
dev=/var
space=800

# Test if we have sufficient space left
if [ $space -lt $needed ] ; then
   kdialog --title "Warning..." \
      --warningyesno "Low on space on $dev - Continue?"
   if [ $? -ne 0 ] ; then
      echo "Copy failed" >> log
      exit $ERR_SPACE
   fi
fi

# Copy here...

echo "Copy ok" >> log

# All done

After calling kdialog we test the answer with '$?'. If it is not zero, which means the user clicked on 'no', we exit the script with the defined error code.

For more options, simply enter 'kdialog --help' on the command line.

Happy scripting!

Wonders of the internet

2008-09-28T22:38:00.003-03:00

The internet is an amazing thing. Sometimes we forget too fast how things used to be before the internet. Yeah, I know, I'm getting old... I started working with computers when there was no such thing as the internet.

Today I was 'Googling' and by coincidence found a page talking about some software I wrote several years ago. It's a simple Hex-editor for Windows written in C, based on much older versions, dating back from the days of CP/M. If you have no idea what CP/M is, you're probably a bit younger than I am ;-)

This version I found today on the internet dates from 2003 / 2004. I published it at the time for free download (I always believed in free software) on my website. I never promoted it too much, but some people managed to find it and at the time I received quite some feedback.

After finding that page, I did a Google search on this Hex Editor and found pages from all over the world mentioning my software :-) Never had any idea my little program has been used in places like Poland, China, etc...

That's the internet: no more distances and complete anonymity.

VMware Problems & Solutions

2008-09-28T11:40:00.005-03:00

I am a big fan of VMware and virtualization in general.
At work we use the professional version to install servers that are only used a couple of hours a week, like systems for testing new releases of software etc.
At home I use the free vmware-server-1.0.7 version to test new releases of software, different operating systems, etc. I used to have several desktops for testing, taking up a lot of space. Now I create and delete virtual machines on my desktop that has lots of hard disk space.
After upgradingmy Slackware 12.1-current with the latest versions of libX11 (1.1.5) and gtk2 (2.12.12) VMware stopped working and presented this error:

vmware: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0 )' failed.

After some research and testing combinations of the previous versions of libX11 and gtk, I found the following solution:
1) Compile an alternative version of libX11 that does not use xcb
2) Always start VMware using this alternative library

The following script downloads the source code of libX11, compiles it with the '--without-xcb' option and creates a start-up script to use this version with VMware:

#!/bin/bash
#
# vmware_no_xcb Script to compile alternative libX11 library
# (without xcb) for vmware with gtk2 > gtk+2-2.12.9
#
# Version: 1.0.1 - Sun, Sep 21, 2008
#
# Author: Niels Horn
#

# Set constants:
libver=libX11-1.1.5
destlib=/usr/local/bin/vmware_no_xcb
destbin=/usr/local/bin

# Download sources from xorg.freedesktop.org:
test -e $libver.tar.bz2 || wget -c http://xorg.freedesktop.org/archive/individual/lib/$libver.tar.bz2

# Clean old dir and extract sources:
rm -rf $libver
tar xjf $libver.tar.bz2

# Create destination for new lib & new startup script:
mkdir -p $destlib
mkdir -p $destbin

# Go into sources dir, configure, compile & strip:
cd $libver
   ./configure --without-xcb
   make -j 2
   strip src/.libs/libX11.so.6.2.0

# Copy new lib to destination & create symlinks:
   cp src/.libs/libX11.so.6.2.0 $destlib
   ln -s libX11.so.6.2.0 $destlib/libX11.so.6
   ln -s libX11.so.6.2.0 $destlib/libX11.so

# Create startup script, using new lib, and make executable:
   echo -e "LD_PRELOAD=$destlib/libX11.so vmware" > $destbin/vmware-start.sh
   chmod 755 $destbin/vmware-start.sh

# Leave sources dir & remove:
   cd ..
rm -rf $libver

# All done. From now on, use 'vmware-start.sh' to start vmware

Substitute the libver, destlib & destbin variables with your preferences and run this script to do the rest for you.
From then on, start VWware with 'vmware-start.sh' to call your new libX11 library.

This works with the 1.0.x versions of VMware. The new 2.x versions are a completely different story for me, but that's for a future post...

'The Man'

2008-09-27T21:47:00.003-03:00

Those who use Slackware will know who Patrick Volkerding is. For those who don't: he is the creator and maintainer of the Slackware Linux distribution. Also known as 'The Man'.
Browsing for articles about the history of Slackware (I might write something about it in the future), I found an interview with Pat from 1994 from Linux Journal.
At that time, I was still completely into DOS and Windows (I 'only' discovered Slackware and Linux in 1996). It is fun to read... It even talks about a possible merger between Slackware and Debian (that never happened, as we now know). And there is a rare picture of 'The Man'...
You can find the interview here.

House-keeping in Linux

2008-09-27T19:04:00.002-03:00

Checked your /tmp folder lately? You might be surprised how many files there are if you do not clean it on a regular basis. To keep mine tidy, I have a small script called 'cleantmp':

#!/bin/bash
find /tmp -atime +5 -exec rm -r {} \;
find /var/tmp -type f -atime +30 -exec rm {} \;

Basically it looks for files in /tmp that are at least five days old and removes them, including subdirectories.
In /var/tmp it allows the files to stay a bit longer: 30 days.

To keep your system clean as well, save this script in /usr/local/bin as 'cleantmp' (or any name you prefer), and make it executable with:

chmod +x /usr/local/bin/cleantmp

Now if your system stays on 24 hours a day, you can schedule this script from crontab:

ln -s /usr/local/bin/cleantmp /etc/cron.daily/cleantmp

But if you normally turn of your computer, you can call 'cleantmp' from /etc/rc.d/rc.local

Happy Slacking!

Traffic Shaping with cbq

2008-09-26T23:42:00.006-03:00

Since I am on the subject of networking in Linux, here is another post about some nice things we can do: shaping our traffic so that we can limit how much of our bandwidth we use for each type of traffic.

Just as a small reminder: I am a long-time Slackware user (since 1996) and I only test my configurations on this distribution. I have used other Linux 'flavors' in the past but know much less about them.
Most thing I will post here will work though on other systems, but don't shoot me if they do not.

I started using cbq for traffic shaping on my local network because of the following situation:
I use rsync to copy some files I cannot afford to loose from my desktop to my wife's and v.v. I use crontab to automatically do this at certain hours.
Rsync is a wonderful protocol that only copies files that have changed, saving time and bandwidth.
But sometimes many files are changed or added, and then the whole bandwith of my local network is used, slowing down other traffic.
At these times even browsing the internet can become very slow, just because I am backing up some folders of new digital pictures.

Rsync has its own '--bwlimit' option, but I wanted a better, more structured solution. And this solution is cbq.

Basically configuring up cbq is done in three steps:

1) Setting up cbq
cbq is actually a script that can be found in the documentation of iproute2 in Slackware. We have to copy it to /sbin and make it executable:

cp /usr/doc/iproute2-2.6.16-060323/examples/cbq.init-v0.7.3 /sbin/cbq
chmod +x /sbin/cbq

cbq expects its configuration files in /etc/sysconfig/cbq
If this directory does not exist, create it:

mkdir /etc/sysconfig/cbq

2) Creating the rules-file
cbq reads files in /etc/sysconfig/cbq with the following names:
cbq-nnnn.yyy where:

nnnn: is a hexadecimal number from 0002 to ffff
yyy: is the name of your network interface, like eth0, eth1, etc

In my case, the network interface for my local network is eth1, so I created "cbq-0002.eth1"
Here is the contents of my file:

DEVICE=eth1,100Mbit,10Mbit
RATE=5000Kbit
WEIGHT=500Kbit
PRIO=5
RULE=192.168.1.110:873,192.168.1.0/24
BOUNDED=no
ISOLATED=no

Some explanations:

DEVICE: the interface you want to limit, with its real speed and its weight (1/10 of the max. speed)
RATE: the bandwith you want to offer for this particular application / port / address
WEIGHT: 1/10 of the RATE
PRIO: Priority setting. 5 is default
RULE: source,destination --> in my case 192.168.1.110 is my desktop, 873 is the port rsync uses
BOUNDED: Default no, used if you have other filters
ISOLATED: 'no' means that the rate can be used by other traffic if not in use

3) Starting the bandwidth limiting
Use cbq compile to prepare the new filters or after you alter your cbq-nnnn.yyy files.
Then use cbq start to start your traffic-shaping!
To always start cbq, include it in your rc.local script.

You can monitor your results with iptraf or wireshark.

More information can be found using "man tc-cbq".

Load Balancing two ISPs

2008-09-26T22:56:00.009-03:00

Today I finally managed to use my two ISPs together on my desktop, combining both bandwidths into one big (almost 3Mbit!) pipe.

My setup:

ADSL modem 1Mb down, 320Kb up
GSM modem 2Mb down, 512Kb up

Configuring both at the same time is simple, but then we have two default gateways and our packets always go out through the first one found (or with the lower cost as defined in the 'metric' parameter.)

So how can we divide our packets over both links?

Googling around I found several suggestions to use iptables.
The general idea is:

use -m statistic in a chain to choose packets to use on of two links (either the 'nth'-method or the 'average'-method
set a mark on the packet
use an 'ip rule' to select a routing table for mark 1, mark 2, etc.

That sounded like a perfect solution. This way I could really balance my two links like 40%/60% or whatever.

But it didn't work...

My desktop is not a router, so I have to treat the packets in the OUTPUT chain, where routing has already taken place. The above-described method works on Linux routers treating the PREROUTING chain in iptables, where we can mark a package before routing.

So I studied IP ROUTE and IP RULES a bit more, browsing through the fantastic Linux Advanced Routing & Traffic Control site.

I discovered that we can use 'nexthop' to 'hop' between several routes.
After experimenting a bit I wrote the following script:

#!/bin/bash
#
# bal_local        Load-balance internet connection over two local links
#
# Version:         1.0.0 - Fri, Sep 26, 2008
#
# Author:          Niels Horn 
#

# Set devices:
DEV1=${1-eth0}    # default eth0
DEV2=${2-ppp0}    # default ppp0

# Get IP addresses of our devices:
ip1=`ifconfig $DEV1 | grep inet | awk '{ print $2 }' | awk -F: '{ print $2 }'`
ip2=`ifconfig $DEV2 | grep inet | awk '{ print $2 }' | awk -F: '{ print $2 }'`

# Get default gateway for our devices:
gw1=`route -n | grep $DEV1 | grep '^0.0.0.0' | awk '{ print $2 }'`
gw2=`route -n | grep $DEV2 | grep '^0.0.0.0' | awk '{ print $2 }'`

echo "$DEV1: IP=$ip1 GW=$gw1"
echo "$DEV2: IP=$ip2 GW=$gw2"

### Definition of routes ###

# Check if tables exists, if not -> create them:
if [ -z "`cat /etc/iproute2/rt_tables | grep '^251'`" ] ; then
   echo "251    rt_dev1" >> /etc/iproute2/rt_tables
fi
if [ -z "`cat /etc/iproute2/rt_tables | grep '^252'`" ] ; then
   echo "252    rt_dev2" >> /etc/iproute2/rt_tables
fi

# Define routing tables:
ip route add default via $gw1 table rt_dev1
ip route add default via $gw2 table rt_dev2

# Create rules:
ip rule add from $ip1 table rt_dev1
ip rule add from $ip2 table rt_dev2

# If we already have a 'nexthop' route, delete it:
if [ ! -z "`ip route show table main | grep 'nexthop'`" ] ; then
   ip route del default scope global
fi

# Balance links based on routes:
ip route add default scope global nexthop via $gw1 dev $DEV1 weight 1 \
   nexthop via $gw2 dev $DEV2 weight 1

# Flush cache table:
ip route flush cache

# All done...

You can download the script here from my homepage.

This is not the perfect solution, as routes are cached, so once you connected to an external site, it will continue to use the linkt hat was originally selected.
So an FTP download won't benefit from this solution, but torrent downloads will, as they use several parallel connections.

I tested the result and managed to download using BitTorrent with the incredible speed of 250KBytes/sec:

Blogging...

2008-09-26T21:21:00.002-03:00

I never wanted to start a blog, for several reasons, but mainly because:

I do not have the time to write regular posts
I really do not have too many interesting facts to share with the world

But it seems that nowadays everyone is blogging all over the world. My wife - who really isn't into computers that much - has a blog and even my son started one.
But hey, I'm self-assured enough to not feel left out yet ;-)
There are other things in life than computers...

I do like to write in forums and newsgroups. I go there to ask questions and to share ideas, solutions, help other people, etc.
Once in a while I write an article about something I found out, a problem I solved or just to receive constructive criticism.

Then some people suggested again I should put these articles in a blog, so that other can find them more easily.

Well, OK, I'll give it a try.

I have lots of stuff here that I wrote down in text files that I might transform into posts in this blog.

Maybe I'll even start enjoying it ;-)