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

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.

Lego & POV-Ray on Linux

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:

1. LeoCAD - to "build" your constrution


2. (optional) a viewer program, like LDView or ldglite


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


4. (optional) The "lgeo" parts collection


5. 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!

Monitoring your network and servers

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.

Lego and Linux (part 5)

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)

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)

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)

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...

Lego and Linux

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:

Flexible scheduling

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

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!

On partitioning your hard drive...

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...

Tux and... Tuz?

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... :-)

KDE Network Configuration tool and Slackware

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

...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

...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!