I also built Hercules for ARMedslack. I believe the SheevaPlug will be an excellent device for demonstrating Hercules as a “portable mainframe”.

The automated rsync script will update the site over the next few hours.

I updated my SlackBuild for the stable version and submitted the result.
Since I was changing the script, I used the opportunity to include the arm architecture and tested the result on ARMedslack, where it worked just fine.

For those who cannot wait until the SlackBuild is approved, or do not want to / know how to build their own software, packages for Slackware 32-bits (”i486″ architecture), Slackware 64-bits (”x86_64″ architecture) and ARMedslack can be downloaded from my site.
Note: the “arm” package is for the newer EABI version of ARMedslack (the -current version) and won’t work on ARMedslack 12.2.

I’ll probably build more packages for ARMedslack when updates of sources are released, so if you are interested in this platform, check back here once in a while…

I have configured several other USB modems on my Slackware systems, so I was sure I could get this one to work as well. I did it in about 20 minutes and here are the basic steps:

1) Switching from “drive” to modem
Many of these USB modems first present themselves as “media”, so that Windows users can install the built-in software from them. Then the installed driver “ejects” the media and the modem presents its real identity as a modem.
On Linux, we have to “eject” the media as well by software, and for this we can use a udev rule.
When plugged in the first time, we can check the ID of the media / modem in a terminal window with lsusb. The result included the following line:

Bus 001 Device 005: ID 0421:060c Nokia Mobile Phones

So this is the ID of the modem presenting itself as removable media.

Now we need a udev rule to “eject” the media. This is what I wrote, based on some previous experience and this guide on writing udev rules:

SUBSYSTEMS=="usb", SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c", ACTION=="add", RUN+="/usr/bin/eject -s %k", OPTIONS+="last_rule"

Now let’s analyze this rule:

• SUBSYSTEMS=="usb" – speaks for itself: we are handling a USB device
• SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c" – this identifies our Nokia modem
• ACTION=="add" – means that this rule is only for when the device is added
• RUN+="/usr/bin/eject -s %k" – calls the “eject” program with the parameters -s (a “SCSI” device, like /dev/s??) and %k (the device name the kernel gave it, like /dev/sdb0 or whatever the “media” is named)
• OPTIONS+="last_rule" – make sure that later rules for this device have no effect

Save this rule as 91-nokiacs10.rules in /etc/udev/rules.d/
This is the directory where we save all our “custom” rules, as opposed to the standard rules that stay in /lib/udev/rules.d where we should not mess around (as they will be overwritten with the next update of udev).

So now, pull out the modem and plug it in again. If everything is fine, after a short time you can check your usb devices again with lsusb and now the line should be:

Bus 001 Device 005: ID 0421:060e Nokia Mobile Phones

Check that the Product ID has changed from 060c to 060e

2) Check your modem device
Now check your devices with ls /dev/tty* and you should see in the list ttyACM0 and ttyACM1.
Use ttyACM0 in your favorite dialer to connect to your internet provider. I use pppd, but it should work with kpppd or whatever you prefer!

3) Next steps
I actually use a second script that automatically “dials” my provider and connects me to the internet. This is done by creating a second rule in the same file, but this time for the 060e device, starting a small shell script.
This script checks if the ttyACM0 device is available, calls pppd, checks ifconfig if the ppp0 device is up and creates an entry in the routing table.
Since my script is very ugly, I won’t put it here, but it was not that difficult to write, so I’ll leave this as an exercise!

Some examples:

1. a torrent program to download all those Linux ISOs (you’re not downloading anything illegal, are you? )
2. an irc program so that you can log all conversations while you’re away
3. a mainframe emulator (well, this was my main reason)

For (1) there is rTorrent and for (2) there is irssi, included in Slackware. For (3) I use Hercules that runs in a terminal screen.
Now services you can start in /etc/rc.d/rc.local, as they do not need a terminal to show output and run as daemons. But these three programs need to show their output on a terminal screen to be useful, and a user that is logged in.
The standard solution for these cases is using “screen”, that lets programs run on “virtual terminal” you can “attach” to.

Since an easy-to-use and still relatively safe setup is a bit tricky, here are a few simple instructions. As an example (not very useful in the real world), I will start “top” at boot time in a screen session.

1. Defining the user that will run the program
First of all, I personally think it is a very bad idea to run programs as root, especially if they need access to drives, the internet, etc. So for my example, I create a user “_top” with the “adduser” command.
I suggest starting the name with the “underline” character, but that’s just a habit I have for special users.
I also create these special users with uid’s in a special range, like 5001-5999.

2. Editing the ~/.screenrc file
After creating your _top user, you will have a file called “/home/_top/.screenrc”
If your version of Linux does not copy it automatically for new users, there should be a “skeleton” version somewhere you can copy.
Edit the copy of .screenrc in the user’s home directory, and add the following lines at the end:

multiuser on
acladd user1,user2,user3

What do these lines mean:

• multiuser on will make the screen session available for other users. Without this line, it would be a “private session”, with only “_top” having access to it.
• acladd user1,user2,user3 gives access to user1, user2 and user3. Replace these with the users you want to be able to attach to the screen session _top will start at boot time.

We’ll come back to this .screenrc file later…

3. Starting screen + the desired program at startup
We will start the program as usual in /etc/rc.d/rc.local by adding the following line:

sudo -H -u _top screen -dmS top /usr/bin/top

Let’s dissect this command:

• sudo rc.local is run by root but not as a logged-in user, so with sudo we tell root that we want the program to start as another user
• -H This tells sudo to use the home directory of the user we choose. Without the -H option, sudo will not find the /home/_top/.screenrc file.
• -u _top Here we define the user – _top in our case.
• screen -dmS top /usr/bin/top This is the command sudo will execute, with these options:
  • -dm Start screen in “detached” mode, not at the current terminal (as we do not have a current terminal, after all we’re not even logged in)
  • S top Use the session name “top” – this is so that we can identify the screen session if we have several of them
  • /usr/bin/top The command screen will run in the “virtual terminal”

4. Trying our first setup
To try this setup, you do not need to boot your server yet. Simply run the sudo -H -u _top screen -dmS top /usr/bin/top as root. It should simply return to the prompt, but we can check if it worked with ps -ef f | grep ^_top that should return with:

_top      1418     1  0 13:40 ?        Ss     0:00 SCREEN -dmS top /usr/bin/top
_top      1419  1418  5 13:40 pts/0    Ss+    0:00  \_ /usr/bin/top

Of course the PIDs and times will be different.

Now log in as one of the users you defined in the acladd line in .screenrc and type screen -ls _top/ where:

• -ls is the option to list all running sessions
• _top/ tells screen to list the sessions of user _top

It should return with:

There is a suitable screen on:
	1418.top	(Multi, detached)
1 Socket in /home/_top/.screen.

• 1418 is the pid – this will change of course
• top is the session name we defined
• Multi means that it is a multiuser session (as defined in .screenrc)
• detached means that no user is attached to the session

So let’s attach to the session and see how “top” is doing, by typing screen -r _top/top
If everything worked fine, you should see “top” as running on your server

Screen has several commands, but for now the most interesting are:

• ctrl-A d – detach from the current session but let it running
• ctrl-A ? – show the ctrl-A commands
• ctrl-A : – gives the prompt in screen to enter commands

5. Adding some security
So now we have a working setup, but all the users we defined in the .screenrc file can access our session (even several at once) and input commands there.
I suggest at least asking for a password before letting a user attach to a session. This is a bit tricky to set up if you have never done this, but these are the basic steps:

1. Attach to a session normally
2. Type ctrl-A c to create a second screen (the first one will still be there)
3. Go to the screen prompt by typing ctrl-A :
4. Enter password + enter and type your password twice
5. The encrypted password will be in screens “paste buffer”
6. Type ctrl-A ] to reveal the encrypted password

Now edit the .screenrc file and change the lines at the end as follows:

multiuser on
acladd user1,user2,user3 xxxxxxxxxxxxx
aclchg * +rwx "#?"

Substitute xxxxxxxxxxxxx with your encrypted password.
The last line gives full access to all users that know the password. According to the manual this should be automatic, but that is not how it worked for me. Without this line I could not even detach from a session! I simply received an error like “detached: permission denied (user: niels)”
You can change the +rwx options for some users, so that they can only “read” the session and not “write” (type) anything. This adds extra security that can be important in some cases.

After finishing editing the .screenrc file, you can close the second session by typing exit at the prompt.

6. Advanced options
There are many more things you can do with screen, like having several users accessing the same session, some only reading, others typing as well. There are also many security adjustments you can configure…

Read the man-page for screen to study all the interesting things you can do!

I used a (quite old) utility called nbench that was originally written in 1995 but still is a simple way to compare how processors perform, emulated or real. And it has a nice advantage that it can be built on x86, s390 and Arm processors without problems.

Here is the result of Slack/390x-11.0 running in Hercules 3.06 with two emulated processors:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          34.476  :       0.88  :       0.29
STRING SORT         :           3.012  :       1.35  :       0.21
BITFIELD            :      8.3237e+06  :       1.43  :       0.30
FP EMULATION        :          2.3056  :       1.11  :       0.26
FOURIER             :          70.649  :       0.08  :       0.05
ASSIGNMENT          :         0.35083  :       1.33  :       0.35
IDEA                :          94.416  :       1.44  :       0.43
HUFFMAN             :          34.368  :       0.95  :       0.30
NEURAL NET          :         0.10472  :       0.17  :       0.07
LU DECOMPOSITION    :          3.5645  :       0.18  :       0.13
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 1.194
FLOATING-POINT INDEX: 0.136
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual IBM/S390
L2 Cache            :
OS                  : Linux 2.4.33.3
C compiler          : gcc version 3.4.6
libc                :
MEMORY INDEX        : 0.278
INTEGER INDEX       : 0.314
FLOATING-POINT INDEX: 0.075
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And here is the result of ArmedSlack running in Qemu:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          199.84  :       5.13  :       1.68
STRING SORT         :          22.453  :      10.03  :       1.55
BITFIELD            :       9.048e+07  :      15.52  :       3.24
FP EMULATION        :          28.281  :      13.57  :       3.13
FOURIER             :          139.34  :       0.16  :       0.09
ASSIGNMENT          :          4.4836  :      17.06  :       4.43
IDEA                :           922.7  :      14.11  :       4.19
HUFFMAN             :          322.93  :       8.95  :       2.86
NEURAL NET          :         0.26406  :       0.42  :       0.18
LU DECOMPOSITION    :          8.8432  :       0.46  :       0.33
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.288
FLOATING-POINT INDEX: 0.313
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.32.7-versatile
C compiler          : gcc version 4.4.3 (GCC)
libc                : libc-2.11.1.so
MEMORY INDEX        : 2.814
INTEGER INDEX       : 2.819
FLOATING-POINT INDEX: 0.174
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And finally, my host system where Hercules and Qemu run:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1339.8  :      34.36  :      11.28
STRING SORT         :          282.56  :     126.26  :      19.54
BITFIELD            :      5.6507e+08  :      96.93  :      20.25
FP EMULATION        :          186.88  :      89.67  :      20.69
FOURIER             :           30009  :      34.13  :      19.17
ASSIGNMENT          :          38.938  :     148.16  :      38.43
IDEA                :            8292  :     126.82  :      37.65
HUFFMAN             :          2983.2  :      82.72  :      26.42
NEURAL NET          :            61.4  :      98.63  :      41.49
LU DECOMPOSITION    :          1939.9  :     100.50  :      72.57
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 92.652
FLOATING-POINT INDEX: 69.676
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz 3010MHz
L2 Cache            : 6144 KB
OS                  : Linux 2.6.32.7-custom64
C compiler          : gcc version 4.4.3 (GCC)
libc                : libc-2.11.1.so
MEMORY INDEX        : 24.774
INTEGER INDEX       : 21.953
FLOATING-POINT INDEX: 38.645
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

As you can see, the S/390 emulation is the one that suffers most. The new s390x 64-bits version performs a bit faster, but the processor on the host machine tops at 100% during more complex tasks.

I won’t put all the different (i486 / x86_64 / arm / s390 / s390x) packages on my site, but I’ll submit the SlackBuild script to SlackBuilds.org, so that you can build them yourself on your machines.

The result was quite usable, at least for the older mainframe operating systems like MVS.

Here are some screenshots:

Starting Hercules on ArmedSlack:

The 3270 terminal connecting to the “Mainframe”:

Hercules working hard doing an IPL:

Performing a clean shutdown of MVS:

More on this project later…

So what better to do than finally test the 64-bits version of Slack/390?

I wrote an 11-part post about installing Slack/390 on Hercules more than a year ago, and it is still valid and can be used for installing the newer version of Slack/390 as well – at least for about 90%.
I did encounter some problems though, but the 64-bits version of Slack/390 is still in the testing phase, so we should give it some credit.

What went wrong:

• The “ramdisk_size” from the supplied parmfile.txt is way too small, I made it 64000 to work
• Some packages were missing (sgml-tools / bin86 / clisp / gcc-gnat), but no show-stoppers
• The “etc” package was not installed, causing some problems with standard users and groups
• The symlink “sh” pointing to “bash” was missing, so none of the rc.* scripts would work (created it manually)
• The “/etc/slackware-version” file was missing

I managed to solve all problems one by one and installed SlackPkg from /extra afterwards to update my installation with the latest packages.
I sent my findings to the maintainers of Slack/390 to that future users won’t have the same challenges that I had

I might write a new series of posts on installing Slack/390, with updated information, but I’ll probably wait until the new version is a bit more stable.

For now, I’m having fun with my new 2x 64-bits emulated Mainframe running Slackware!

There are actually several solutions for this, like DynDNS, where you can register a domain like <yourname>.selfip.net (and many other combinations). Then you will need a “client” – a small piece of software that checks every so many minutes if your IP address has changed.

For Linux systems, there is inadyn. I have been using inadyn for a couple of years now and it has been extremely stable and useful for me. You can download a ready-to-use binary from their site, but it is 32-bits only.
Since the sources are also available, I decided to create a SlackBuild for it, so that inadyn can be used on SlackWare64.

The SlackBuild has been submitted to SlackBuilds.org and is waiting for approval in the pending queue.
If you can’t or don’t want to wait, the packages are also available from my site.

The last few days I was struggling with the following situation:

• I wanted to examine some packets passing through my firewall
• my firewall is a “headless” (this means without a monitor, accessible only via ssh) Slackware server
• it has no X installed (and therefor no window manager etc.) so it won’t run wireshark

Now wireshark can read packets captured by tcpdump and written to a file, so that’s what I did at first:

• capture with tcpdump
• write the packets to a file on a network share
• open the file with wireshark

The problem is that I wanted to examine the packets “on-line”, as they pass through the firewall.
Linux has a solution (inherited from Unix) for this, called “pipes”. These are a special kind of files, where one program writes, while another reads from it, getting the contents in the right order.
In other words: the packet that went into the pipe first, will come out first at the other site of the pipe. Imagine it as a “vitrual tube”.

It was a bit of a struggle to get all the parameters right, but in the end, I got it working like this (note: all commands are entered in a terminal session on the desktop):

1. Create the pipe

niels@desktop:~$ mkfifo /tmp/pipes/cap_fw
“/tmp/pipes/” is where I create my pipes, feel free to use whatever directory you prefer.
“cap_fw” is the name of the pipe I selected.

2. Start tcpdump remotely with ssh from the desktop where you have wireshark installed:

niels@desktop:~$ ssh root@<firewall> "tcpdump -s 0 -U -n -w - -i eth1 not port 22" > /tmp/pipes/cap_fw
Replace <firewall> with the name or ip address of your remote server.

The options I used are:
-s 0 : use the required length to catch whole packets
-U : packet-buffering – write packet to pipe as soon as it is captured (as opposed to waiting for the buffer to fill)
-n : no address-to-name conversion (you can let wireshark do this if you want)
-w - : write output to standard output
-i eth1 : capture from interface eth1 – change to match your setup
not port 22 : leave out any packets from / to port 22. This is needed as we use ssh to connect to out firewall, so that we don’t capture the captured packets again… If you need to examine port 22 on your server, use ssh over an alternative port.
> /tmp/pipes/cap_fw : redirect the output to our pipe.

3. While tcpdump is capturing packets and sending them to the pipe, open another terminal, start wireshark and use the pipe as the input

niels@desktop:~$ wireshark -k -i /tmp/pipes/cap_fw
Here the options mean:
-k : start immediately
-i /tmp/pipes/cap_fw : use our pipe as the “interface”

And you’re up and running!
You can use all the normal functions of wireshark, like filtering, etc., as if you were capturing from a local interface.

By special request from BP{k}, here is a diagram of the setup showing how ssh gets the data from the server, captured by tcpdump and sends it through the pipe to wireshark (with a little help from LeoCAD, l3p and POV-Ray):

(click on the image to enlarge it)

I might write a nice bash script to make things simpler now that I figured it all out.
If it is good enough in the end, I’ll publish it here on my blog.

I decided to build the program and found out it was a nice e-book reader, with some extra features that caught my attention. The nicest was that it can automatically search and download books by author from some on-line “libraries”, which makes it quite simple for the non-technical user to get & read some of the classics.

Here are some screenshots of the program, opening the on-line library and getting a famous book by Arthur Conan Doyle:

Since the Slackbuild was unmaintained, I resubmitted it for the newest version, together with the needed liblinebreak library.
Both will be available on SlackBuilds.org soon, but if you can’t wait, you can download packages for Slackware from my site.