ToC Home Issues Hearts Links

Issue #5, September 2006

Slack Tips

In this issue, you will find the following materials:


Cleaning out old kernels & modules

From: Grant Coady
Date: June 9 2006
Newsgroup: alt.os.linux.slackware
(Original post)

Hi there,

I build lots of linux-kernels, old ones accumulate, along with their /lib/modules/`uname -r` files. For years, I'd occasionally go into a machine as root and manually delete the accumulated dross in /boot and /lib/modules.

Finally got around to writing a bash script that reads /etc/lilo.conf and deletes unreferenced kernel files. Two runs, one through /boot, another through /lib/modules discover stale kernels and modules and remove them.

The script is part of a set of updated kernel-build scripts I'm writing, see it here:

http://bugsplatter.mine.nu/bash/kernel/rm-old-kernels

Along with some notes and other kernel build scripts under:

http://bugsplatter.mine.nu/bash/kernel/

Cheers,
Grant.

A local copy of the script is available here.


Restoring LILO

From: Terrance N. Phillip
Date: 18 November, 2005
Newsgroup: alt.os.linux.slackware (Original post)

Okay, suppose I have a dual boot machine, something like this:
    hda1 - small, vendor proprietary partition
    hda2 - windows 98
    hda3 - linux swap
    hda4 - linux (reiserfs)
And everything's working smoothly. Lilo was installed using MBR.
Someone, NOT SAYING WHO, does a fdisk /mbr from Windows, and now
the computer boots only to windows, never see the Lilo screen.

Is there a quick way to restore Lilo using the installation CD
without re-installing?


From: Ron Gibson
Date: November 23 2005
Newsgroup: alt.os.linux.slackware
(Original post)

In general one can always use any bootable CD nearly

  1. Boot CD
  2. mkdir /mount
  3. mount /dev/<your old root partition> /mount
  4. chroot /mount
  5. source /etc/profile
  6. lilo -b /dev/<your old root partition> -v -t
  7. If above reports no errors...
   lilo -b /dev/<your old root partition> -v

Since your old lilo.conf is still intact and you had it in the MBR the OP could simply do a...

   lilo -v -t
   lilo -v

However I would check /etc/lilo.conf first to be sure. One could use mc for a fast check.

The above steps should cover most cases.


Setup multi-ip on one card

From: pipehappy@gmail.com
Date: April 24 2006
Groups: alt.os.linux.slackware (Original post

Hello everyone here:

I have installed 10.2 on the box and want to set up two ip on one card,
one is for outer connection and the other one is for private network.
Can anyone here show me how to do this work? I write some ifconfig in
my rc.local. But I think /etc/rc.d/rc.inet1.conf is prefered place to
tell slackware what I want. And I know ip alias may be necessary. But
at last, what should I do?


From: Eric Hameleers
Date: April 24 2006
Newsgroup: alt.os.linux.slackware
(Original post)

You can just as well configure eth0 as, say, eth0:1 in rc.inet1.conf. For instance:

   # Config information for eth0
   IPADDR[0]="192.168.0.1"
   NETMASK[0]="255.255.255.0"
   USE_DHCP[0]=""
   DHCP_HOSTNAME[0]=""

   # Config information for eth0:1
   IFNAME[1]="eth0:1"
   IPADDR[1]="192.168.1.12"
   NETMASK[1]="255.255.255.0"
   USE_DHCP[1]=""
   DHCP_HOSTNAME[1]=""

This will work, as long as you place the definition of the alias (eth0:1 in this example) after the definition of the interface (eth0) itself.


rc.local not finishing

From: cyber0ne
Date: March 10 2006
Newgroup: alt.os.linux.slackware (Original post)

I'm trying to add some services to my boot sequence, and I'm under the
impression that I can accomplish this by adding their SysV init scripts
to rc.local, right?  So here is my rc.local file:

--------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.local:  Local system initialization script.
#
# Put any local setup commands in here:

# Start IMAP
if [ -x /etc/rc.d/rc.imap ]; then
  . /etc/rc.d/rc.imap start
fi

# Start IMAP-SSL
if [ -x /etc/rc.d/rc.imaps ]; then
  . /etc/rc.d/rc.imaps start
fi

# Start SpamAssassin
if [ -x /etc/rc.d/rc.spamd ]; then
  . /etc/rc.d/rc.spamd
fi

# Start Authlib
if [ -x /etc/rc.d/rc.authlib ]; then
  . /etc/rc.d/rc.authlib
fi

# All done.
--------------------------------

Problem is, no matter what order I put these in, only the first one
gets executed.  The other three are ignored.  Did I do something wrong
here that would cause the whole thing to exit once the first one is
done?  How can I get all four (and subsequent future additions) to be
executed?

Regards,
David P. Donahue
http://www.cyber0ne.com


From: Joost Kremers
Date: March 10 2006
Newsgroup: alt.os.linux.slackware
(Original post)

i had the same problem in my rc.local, and your message prompted me to do some searching. i found my problem, and i'm guessing yours is the same: my guess is that each of the rc scripts that you source in your rc.local ends in 'exit 0'. the problem is that the rc scripts are sourced, i.e., the commands in them are executed in the same shell as rc.local. that means that when an exit command is encountered in one of the sourced scripts, the shell running rc.local will terminate.

note that if you grep the rc scripts, you won't find that many that actually use exit statements. and the ones that do (rc.cups is one) are not sourced, but executed. rc.M for example has this:

   #v+

   if [ -x /etc/rc.d/rc.cups ]; then
     # Start CUPS:
     /etc/rc.d/rc.cups start
   elif [ -x /etc/rc.d/rc.lprng ]; then
     # Start LPRng (lpd):
     . /etc/rc.d/rc.lprng start
   fi

   #v-

notice how rc.cups is executed, but rc.lprng is sourced?

so the solution to your problem is obviously not to source your rc scripts in rc.local but to call them.


How to turn on DMA?

From: dieymir
Date: June 29 2006
Groups: alt.os.linux.slackware
(Original post)

I have done a script to set hdparm options, maybe some of you find it useful: put both files, rc.hdparm and rc.hdparm.conf in /etc/rc.d.

I call it from rc.S just bellow synchronizing UMSDOS file system and before setup /etc/motd.


Installing TTF fonts in Slackware

From: Thomas Ronayne
Date: December 23 2005
Groups: alt.os.linux.slackware
Original post

If you're just missing TTFs, you don't need to build anything, you just need to install the fonts -- here's a guide from a while back that shows how to do that.

Assuming you have a bunch of TTF font files (from wherever you got them), it's pretty easy:

   log in as root (or su or whatever)
   cd directory-where-TTF-files-are
   #   create the target directory if it doesn't already exist
   mkdir -p /usr/X11R6/lib/X11/fonts/TTF

   #   copy all the TTF files, changing the name to lower case as you go
   for file in *.[Tt][Tt][Ff]
   do
     cp ${file} /usr/X11R6/lib/X11/fonts/TTF/`echo ${file} | tr [A-Z] [a-z]`
   done

   #   go to the directory you just copied all that stuff to
   cd /usr/X11R6/lib/X11/fonts/TTF

   #   if you got them from winders, change the mode of the files
   chmod 644 *

   #   create the fonts.dir and fonts.scale files you need
   mkfontscale
   mkfontdir

You should have files fonts.dir and fonts.scale, look at 'em if you want

Now you need to add the font path to /etc/X11/xorg.conf; in the section "Files," add this line:

   FontPath     "/usr/X11R6/lib/X11/fonts/TTF/"

That section of my xorg.conf file looks like this:

   Section "Files"
           RgbPath      "/usr/X11R6/lib/X11/rgb"
           ModulePath   "/usr/X11R6/lib/modules"
           FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
           FontPath     "/usr/X11R6/lib/X11/fonts/TTF/"
           FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
   #       FontPath     "/usr/X11R6/lib/X11/fonts/CID/"
           FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
           FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
   EndSection

You need to exit from X (if it's running) and execute

   fc-cache /usr/X11R6/lib/X11/fonts/TTF

Then restart X.

That's it.

--
Everything works -- if you let it.


Remark 1.

There has been a fix to the post pointing that one should create /etc/fonts/local.conf looking this way:

   <fontconfig>
    <dir>/usr/X11R6/lib/X11/fonts/TTF/</dir>
   </fontconfig>

but Thomas Ronayne pointed out that this line is already present in /etc/fonts/fonts.conf.

It is advised to create /etc/fonts/local.conf in case a directory other than the ones listed in /etc/fonts/fonts.conf is used to add fonts. As it was explained by Melissa Danford, "The motivation behind using local.conf is that local.conf will not be overwritten by fontconfig while fonts.conf will be."

Remark 2.

Running the command

   fc-cache /usr/X11R6/lib/X11/fonts/TTF

may not be needed, at least in KDE 3.5, because ~/.fonts.cache-1 file is automatically created when KDE is started if /usr/X11R6/lib/X11/fonts/TTF/fonts.cache-1 is outdated or missing.


How do I stop ssh tunneling?

Mikhail Zotov

Suppose you have a multi-user Linux machine at the place you work, and many of the users are students curious about computing, hacking, and all that. With the low prices on ADSL connections, many of them have home machines with real IP addresses staying on-line 24/7. Obviously, some of them can come to an idea of establishing an ssh tunnel between a workstation in the lab and their home PC. Incoming connections to the workstation are stopped by a firewall but numerous resources available in the Net provide detailed tutorials on establishing remote port forwarding (with the -R option of ssh). Surprisingly, it is much more difficult to find a document explaining how an administrator can prevent this.

Let's consider a number of simple options.

1. Don't allow students to use ssh:

   # chmod 0750 /usr/bin/ssh

and, optionally,

   # chgrp ssh /usr/bin/ssh

This is not an option in our case because students need to connect to a remote Linux cluster via ssh to perform calculations. Obviously, we can enable something like sudo ssh remote_host but then we have to instruct them about using sudo, which is boring. :-)

2. Stop the ssh server running on the workstation. The point is that remote port forwarding needs ssh servers to be running on both ends of the tunnel.

Again, this is not a good option in our case because it makes (lazy) system administrators to log in the workstation via console (or a serial line). They don't like the idea. :-) Surely, the ssh server can be started via port knocking but this is not a completely secure solution, and this seems to be an overkill.

3. "Linux System Security: The Administrator's Guide to Open Source Security Tools" by Scott Mann, Mitchell Krell and Ellen Mitchell suggests that one compiles openssh with the --disable-client-port-forwarding option. I tried to do this with openssh-4.3p2 but this didn't help. Actually, configure --help didn't show this as a supported option at all.

4. Fortunately, there is a trivial solution to the problem. Add

   AllowGroups admin

to /etc/ssh/sshd_config. This prevents all users that don't belong to the admin group to log into the workstation via ssh. This doesn't stop them from guessing a password of a member of the admin group though. Well, this is also a snap: just change the default setting

   PasswordAuthentication yes

in /etc/ssh/sshd_config to read

   PasswordAuthentication no

and you are done. At least, I think so. :-)

Remark. When the issue was ready, I found another approach to the problem suggested in Issue 1.8 (September 2006) of (IN)SECURE Magazine.



BerliOS Logo