Showing posts with label slackware. Show all posts
Showing posts with label slackware. Show all posts

01 May, 2013

Installing OSSEC agent

With the recent news about the latest Apache backdoor on systems using cPanel, I thought it would be pertinent to show the process of adding an OSSEC agent that connects to a Security Onion server. Why is this relevant? Because OSSEC and other file integrity checkers can detect changes to binaries like Apache's httpd.

"OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response."
Many systems include integrity checking programs in their default installs these days, for instance Red Hat with AIDE. AIDE is also available in repositories for a number of other Linux distributions plus FreeBSD.

This case in particular would require using something other than the default options for integrity checking because cPanel installs Apache httpd in /usr/local/apache/bin, a non-standard directory that may not be automatically included when computing file hashes and doing subsequent integrity checks.

The reason I'm demonstrating OSSEC here is that it easily integrates with the Sguil console, and in Security Onion the sensors and server already have OSSEC configured to send alerts to Sguild. OSSEC also has additional functionality compared to AIDE. In this case, I'm installing the agent on a Slackware server.
$ wget http://www.ossec.net/files/ossec-hids-2.7.tar.gz

---snipped---

 $ openssl sha1 ossec-hids-2.7.tar.gz
SHA1(ossec-hids-2.7.tar.gz)= 721aa7649d5c1e37007b95a89e685af41a39da43
 $ tar xvzf ossec-hids-2.7.tar.gz

---snipped---

 $ sudo ./install.sh

  OSSEC HIDS v2.7 Installation Script - http://www.ossec.net

 You are about to start the installation process of the OSSEC HIDS.
 You must have a C compiler pre-installed in your system.
 If you have any questions or comments, please send an e-mail
 to dcid@ossec.net (or daniel.cid@gmail.com).

  - System: Linux webserver 3.8.4
  - User: root
  - Host: webserver
 
   -- Press ENTER to continue or Ctrl-C to abort. --

 
 1- What kind of installation do you want (server, agent, local, hybrid or help)? agent
 
  - Agent(client) installation chosen.

 2- Setting up the installation environment.

  - Choose where to install the OSSEC HIDS [/var/ossec]:
 
 3- Configuring the OSSEC HIDS.

   3.1- What's the IP Address or hostname of the OSSEC HIDS server?: 192.168.1.20
 
  - Adding Server IP 192.168.1.20

   3.2- Do you want to run the integrity check daemon? (y/n) [y]:

    - Running syscheck (integrity check daemon).

   3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
 
 - Running rootcheck (rootkit detection).

   3.4 - Do you want to enable active response? (y/n) [y]:

3.5- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/adm/syslog
    -- /var/adm/auth.log
    -- /var/adm/messages
    -- /var/log/xferlog
    -- /var/log/proftpd.log
    -- /var/log/apache/error_log (apache log)
    -- /var/log/apache/access_log (apache log)
    -- /var/log/httpd/error_log (apache log)
    -- /var/log/httpd/access_log (apache log)

  - If you want to monitor any other file, just change
   the ossec.conf and add a new localfile entry.
   Any questions about the configuration can be answered
   by visiting us online at http://www.ossec.net .

   --- Press ENTER to continue ---

---snip---

- Init script modified to start OSSEC HIDS during boot.
 - Configuration finished properly.
 - To start OSSEC HIDS:
                /var/ossec/bin/ossec-control start
 - To stop OSSEC HIDS:
                /var/ossec/bin/ossec-control stop
 - The configuration can be viewed or modified at /var/ossec/etc/ossec.conf

    Thanks for using the OSSEC HIDS.
    If you have any question, suggestion or if you find any bug,
    contact us at contact@ossec.net or using our public maillist at

    ossec-list@ossec.net
    ( http://www.ossec.net/main/support/ ).

    More information can be found at http://www.ossec.net

    ---  Press ENTER to finish (maybe more information below). ---

 - You first need to add this agent to the server so they 
   can communicate with each other. When you have done so,
   you can run the 'manage_agents' tool to import the 
   authentication key from the server.

   /var/ossec/bin/manage_agents

   More information at: 
   http://www.ossec.net/en/manual.html#ma

Next, I add the agent to my Security Onion server.
$ sudo /var/ossec/bin/manage_agents 

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************

   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.

Choose your action: A,E,L,R or Q: A

- Adding a new agent (use '\q' to return to the main menu).

  Please provide the following:
   * A name for the new agent: webserver
   * The IP Address of the new agent: 192.168.1.5
   * An ID for the new agent[001]: 

Agent information:

   ID:001
   Name:webserver
   IP Address:192.168.1.5

Confirm adding it?(y/n): y

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************

   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.

Choose your action: A,E,L,R or Q: e

Available agents: 

   ID: 001, Name: webserver, IP: 192.168.1.5

Provide the ID of the agent to extract the key (or '\q' to quit): 001

Agent key information for '001' is: 

---snip---

** Press ENTER to return to the main menu.

Now copy the key, go back to the web server, paste and import the key.
$ sudo /var/ossec/bin/manage_agents 

****************************************
* OSSEC HIDS v2.7 Agent manager.     *
* The following options are available: *
****************************************

   (I)mport key from the server (I).
   (Q)uit.

Choose your action: I or Q: i

* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.

Paste it here (or '\q' to quit): ---snip---

Agent information:
   ID:001
   Name:webserver
   IP Address:192.168.1.5

Confirm adding it?(y/n): y

If I was running a system with cPanel that was vulnerable to Cdorked.A then I would want to make sure OSSEC is monitoring the directories with the Apache httpd files. The OSSEC default configuration from my recent install is /var/ossec/etc/ossec.conf and the relevant lines are below:
<syscheck>
    <!-- Frequency that syscheck is executed - default to every 22 hours -->
    <frequency>79200</frequency>
    
    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/bin,/sbin</directories>

So by default OSSEC would apparently not be checking the integrity of cPanel's Apache installation and I would need to add /usr/local/apache to the directory checks. After making any changes for my particular system, I check the status of OSSEC and it is not yet running.
$ sudo /etc/rc.d/rc.ossec status
ossec-logcollector not running...
ossec-syscheckd not running...
ossec-agentd not running...
ossec-execd not running...
$ sudo /etc/rc.d/rc.ossec start 
Starting OSSEC HIDS v2.7 (by Trend Micro Inc.)...
Started ossec-execd...
Started ossec-agentd...
Started ossec-logcollector...
Started ossec-syscheckd...
Completed.

Note after adding the OSSEC agent on the remote system then adding it on the OSSEC server, you must restart ossec-hids-server in order for the ossec-remoted process to start listening on 1514/udp for remote agents.
$ sudo /etc/init.d/ossec-hids-server status
ossec-monitord is running...
ossec-logcollector is running...
ossec-remoted not running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild not running...
ossec-execd is running...
$ sudo /etc/init.d/ossec-hids-server restart
Killing ossec-monitord .. 
Killing ossec-logcollector .. 
ossec-remoted not running ..
Killing ossec-syscheckd .. 
Killing ossec-analysisd .. 
ossec-maild not running ..
Killing ossec-execd .. 
OSSEC HIDS v2.6 Stopped
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
OSSEC analysisd: Testing rules failed. Configuration error. Exiting.
2013/04/30 23:13:59 ossec-maild: INFO: E-Mail notification disabled. Clean Exit.
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

$ sudo /etc/init.d/ossec-hids-server status
ossec-monitord is running...
ossec-logcollector is running...
ossec-remoted is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild not running...
ossec-execd is running...

$ netstat -l | grep 1514
udp        0      0 *:1514                  *:*    

Note the error corresponding to the FAQ entry about getting an error when starting OSSEC. However, since I'm running OSSEC 2.7 this did not seem to apply. Poking around, I realized the ossec-logtest executable had not been copied to /var/ossec/bin when I ran the install script. After I manually copied it to the directory, restarting OSSEC no longer caused the "Testing rules failed" error.

Once you have installed OSSEC on the system to be monitored, added the agent on the server, imported the key on the system to be monitored, restarted the server process, and started the client process, you will start getting alerts from the newly added system in Sguil. For example, the content of Sguil alerts will look like this after updating gcc:
Integrity checksum changed for: '/usr/bin/gcc'
Old md5sum was: '764a405824275d806ab5c441516b2d79'
New md5sum is : '6ab74628cd8a0cdf84bb3329333d936e'
Old sha1sum was: '230a4c09010f9527f2b3d6e25968d5c7c735eb4e'
New sha1sum is : 'b931ceb76570a9ac26f86c12168b109becee038b'

In the Sguil console, if I wanted to view all the recent OSSEC alerts I could perform a query as pictured below. Note you need to escape the brackets or remove them in favor of the MySQL wildcards '%%'.


Finally, to show an example of the various types of alerting that OSSEC can do in addition to checksum changes, here is a query and output directly from the MySQL console.
mysql> SELECT count(signature),signature FROM event WHERE signature LIKE '%%OSSEC%%' GROUP BY signature ORDER BY count(signature) DESC;
+------------------+---------------------------------------------------------------------------------------+
| count(signature) | signature                                                                             |
+------------------+---------------------------------------------------------------------------------------+
|              388 | [OSSEC] Integrity checksum changed.                                                   |
|              149 | [OSSEC] Host-based anomaly detection event (rootcheck).                               |
|               46 | [OSSEC] Integrity checksum changed again (2nd time).                                  |
|               39 | [OSSEC] IP Address black-listed by anti-spam (blocked).                               |
|               12 | [OSSEC] Integrity checksum changed again (3rd time).                                  |
|                4 | [OSSEC] Web server 400 error code.                                                    |
|                3 | [OSSEC] Receipent address must contain FQDN (504: Command parameter not implemented). |
+------------------+---------------------------------------------------------------------------------------+
7 rows in set (0.00 sec)
The highest count alert, plus the alerts indicating "2nd time" and "3rd time", are the basic functionality needed to detect changes to a file, my original use case. The "rootcheck" is alerting on files owned by root but writable by everyone. The balance of the alerts are from reading the system logs and detecting the system rejecting emails (anti-spam, 504) or web server error codes.

Back to the original problem of Cdorked.A, the blog posts on the subject also indicate that NSM could detect unusually long HTTP sessions, and there are no doubt other network behaviors that could be used to create signatures or network analytics resulting in detection. File integrity checks are just one possible way to detect a compromised server. Remember you need to have known good checksums for this to work! You ideally install something like OSSEC prior to the system being live on the network or at the least prior to it running any listening services that could be compromised before computing the checksums.

26 March, 2012

Updating to Snort 2.9.2 and Barnyard2

After fixing hardware problems that had my home network sensor out of commission for the better part of a year, I recently got the system inline again. Because the sensor had been down for so long, I was running a fairly old version of Snort, 2.9.0.3, along with barnyard 0.2.0. I decided the first thing I should do after updating the OS itself was update Snort and Barnyard.

I won't go through the process in detail since there are many resources online for installing and configuring Snort. The main thing I will point out is that you should always look in the docs/ directory for information on installing and upgrading. If you're updating from a previous version, pay particular attention to changes and new features. Another important thing to do is look closely at the snort.conf provided with a given version in etc/ since it will have a lot of information on defaults and configuration directives that may be required. These won't always be the same as previous versions. It's also important to update to the latest rule sets, check for new rules files, and do all the other normal tuning to make sure certain rules are turned off or on.

I had two main problems when I updated, one with Snort and one with Barnyard2. Since Snort is the main piece of the puzzle here, I updated it prior to Barnyard. After updating to Snort-2.9.2.1 and fixing the configuration, I was able to run Snort successfully using the options I normally had previously. However, as soon as I put the sensor back inline and Snort started processing packets, Snort would exit with an error.

Can't acquire (-1) - ipq_daq_acquire: ipq_read=-1 error Failed to receive netlink message!

A quick search revealed that I had to remove the ip_queue module. JJ Cummings on the #snort channel pointed out to me that NFQ is the more recent option than IPQ. I am using Slackware-current, so even though it is a maintained distribution it is also not surprising that I was using an older option. Slackware also did not have a couple of the required libraries to compile DAQ with support for NFQ, so I went to Slackbuilds.org to get the files allowing me to create Slackware packages for libnetfilter_queue and libnfnetlink.

Once I got the new packages installed, made sure the ip_queue module wasn't loaded, recompiled DAQ to support NFQ, and changed my Snort init to use --daq nfq, my inline Snort was working once again.

Next, I updated from Barnyard-0.2.0.

$ barnyard2 -V

  ______   -*> Barnyard2 <*-
 / ,,_  \  Version 2.1.10-beta2 (Build 266) TCL
 |o"  )~|  By Ian Firns (SecurixLive): http://www.securixlive.com/
 + '''' +  (C) Copyright 2008-2011 Ian Firns


Barnyard2 is needed to process Snort's newer output mode, unified2. My snort.conf changed from:

output log_unified: filename unified.log, limit 128

to:

output unified2: filename unified.log, limit 128

When I got Barnyard2 up and running, it was obviously not successfully processing the unified2 files from Snort. Barnyard2 kept repeating the following error as it tried to process the files.

WARNING: No function defined to read header.

I found a thread on the snort-users list that indicated Barnyard2 was getting a file type it wasn't expecting, which made sense considering the warning message. This issue gave me more problems than it should have and I eventually realized it was because of an error in my barnyard.conf file. The input is supposed to read "input unified2" but I had somehow managed to include a colon after "input". Once I fixed that line, Barnyard2 started working, with alerts being properly processed and showing up in Sguil once again.

The next update will be to go from Sguil-0.7.0 to Sguil-0.8.0.

02 December, 2010

Using slackbuilds.org to create Slackware packages

Sorry for the long posting hiatus but don't expect it to end. I just don't have a lot of time or material to devote to the blog right now.

I recently wanted to upgrade Postfix on my Slackware mail server. I used to use packages from LinuxPackages.net for unofficial packages, but the site has gotten less active and always had a reputation for varying package quality. My preference is using the SlackBuilds to build my own packages. It's fairly simple to download their build script, edit as needed, then build a Slackware package from source.

Since Postfix is not available from Slackware official repositories, I downloaded the SlackBuild files and then the Postfix source.

$ wget http://postfix.cs.utah.edu/source/official/postfix-2.6.8.tar.gz 
$ wget http://slackbuilds.org/slackbuilds/13.1/network/postfix.tar.gz
$ tar xvzf postfix.tar.gz
$ ls postfix/
README     postfix-2.6.8.tar.gz  postfix.info  slack-desc
doinst.sh  postfix.SlackBuild*   rc.postfix
I am using Cyrus-SASL, so it was important for me to note the following from the SlackBuild Postfix page.
This script builds postfix with support for Dovecot SASL but does not
include any support for Cyrus-SASL. If you need to enable support for
Cyrus see SASL_README in the source code.
I also noted the following from the postfix.SlackBuild file itself.
# Postfix unfortunately does not use a handy ./configure script so you
# must generate the makefiles using (what else?) "make makefiles". The
# following includes support for TLS and SASL. It should automatically
# find PCRE and DB3 support. The docs have information for adding
# additional support such as MySQL or LDAP.
I changed the "make makefile" lines from:
make makefiles \
  CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DUSE_TLS' \
  AUXLIBS="-lssl -lcrypto"
to:
make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DHAS_PCRE \
                 -I/usr/local/include/sasl -I/usr/include" \
                 AUXLIBS="-L/usr/local/lib -lsasl2 -L/usr/lib -lpcre"
This added Cyrus-SASL support and also fixed a problem I was having with it finding PCRE. I also changed the VERSION variable to 2.6.8 since the postfix.SlackBuild file was for 2.6.1. After the changes, all I have to do is run the postfix.SlackBuild file then use "upgradepkg" on the resulting postfix-2.6.8-iX86-1_SBo.tgz package. (Note that official packages use xz for compression now, not gzip, so they will have the extension txz).

The next package I will create using SlackBuilds is cyrus-imapd since it also is not included in Slackware. Cyrus-SASL actually has an official package, but I I've been running Cyrus for so long that I have always installed it from source. I don't remember if that is because it wasn't available as a package back in the day or just because I was using some non-standard options.

14 March, 2010

March Slackware-current: libblkid.so.1

 The Slackware-current updates from March 1, 2010, included updates to both the e2fsprogs package and the util-linux-ng package. An important thing to note is that libblkid was moved out of e2fsprogs and into util-linux-ng. If you search the web for libblkid.so.1, slackpkg, util-linux-ng, and e2fsprogs, you will see various forum posts about not being able to boot. This is because libblkid.so.1 is required to mount and the updates included a new kernel, which meant a lot of people updated then rebooted without having util-linux-ng installed.  Booting without the library will get you error messages about libblkid.so.1 not being found when the system tries to mount the drives.

$ man libblkid
LIBBLKID(3)                                                        LIBBLKID(3)

NAME
       libblkid - block device identification library

SYNOPSIS
       #include 

       cc file.c -lblkid

DESCRIPTION
       The  libblkid  library  is used to identify block devices (disks) as to
       their content (e.g.  filesystem type) as well as extracting  additional
       information  such  as  filesystem  labels/volume  names, unique identi-
       fiers/serial numbers, etc. 
If you don't already have util-linux-ng installed then make sure to install it before rebooting since the update to e2fsprogs will remove libblkid.
$ sudo slackpkg update
---snip---
$ sudo slackpkg install util-linux-ng
---snip---
$ sudo slackpkg install-new
---snip---
$ sudo slackpkg upgrade-all
If you get stuck because you ran upgrade-all, don't have util-linux-ng installed, then rebooted for the kernel update, you can boot to the Slackware install CD or DVD so you can install the old version of e2fsprogs or the new util-linux-ng. This will allow you to boot normally then fix whatever is needed, such as installing the new util-linux-ng and/or upgrading e2fsprogs.

13 March, 2010

Customizing Slackware Tcl Package for Sguil

Most distributions these days are configuring their Tcl packages with --enable-threads as a default. Slackware-current switched some months back with the following in the ChangeLog.txt.

+--------------------------+
Mon Dec  7 02:13:13 UTC 2009
d/ruby-1.9.1_p243-i486-3.txz:  Rebuilt.
  Added an explicit --enable-pthread.  This is mostly to make sure that we get
  the expected option set from future releases of Ruby -- it appears that not
  only is --enable-pthread the default in ruby-1.9.1, but trying to use
  --disable-pthread doesn't work.  Furthermore, Ruby and Tcl/Tk no longer work
  together unless both Ruby and Tcl/Tk are compiled with thread support.
  Compiling Tcl/Tk with thread support has caused some problems in the past.
  If a threaded Tcl app tries to fork(), it will hang, but by now most affected
  Tcl apps (such as eggdrop) should have patches available.
  Anyway, this should fix the issues with Ruby and Tk.  Please test it, and
  report any other problems that arise.
tcl/tcl-8.5.8-i486-1.txz:  Upgraded.
  Compiled using --enable-threads, since Ruby requires it to work with Tk.
tcl/tclx-8.4-i486-3.txz:  Rebuilt.
  Recompiled using --enable-threads.
tcl/tix-8.4.3-i486-2.txz:  Rebuilt.
  Recompiled using --enable-threads.
tcl/tk-8.5.8-i486-1.txz:  Upgraded.
  Compiled using --enable-threads, since Ruby requires it to work with Tk.
+--------------------------+ 
The Sguil daemon will not work with threaded Tcl, so to fix this you need to build a package for the distribution of your choice with the --disable-threads configure option. In Slackware and most other distributions, it is fairly simple to customize a package.

Download Tcl from the source directory on the Slackware mirror of your choice. It should include a slack-desc file, a tcl.SlackBuild file, and the Tcl source. Modify the tcl.SlackBuild file to replace --enable-threads with --disable-threads.
./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --enable-shared \
  --disable-threads \
  --enable-man-symlinks \
  --enable-man-compression=gzip \
  ${CONFARGS} \
  --build=$ARCH-slackware-linux
You may also want to modify the slack-desc to note that this is a non-threaded version. Then build the new package.
$ sh tcl.SlackBuild
---snip--- 
Slackware package /tmp/tcl-8.5.8-i486-1.txz created.
As you see, the package will get written to /tmp by default. Now replace the threaded version with the new non-threaded version.
$ sudo upgradepkg --reinstall /tmp/tcl-8.5.8-i486-1.txz
+==============================================================================
| Upgrading tcl-8.5.8-i486-1 package using /tmp/tcl-8.5.8-i486-1.txz
+==============================================================================

Pre-installing package tcl-8.5.8-i486-1...

Removing package /var/log/packages/tcl-8.5.8-i486-1-upgraded-2010-03-13,20:03:22...

Verifying package tcl-8.5.8-i486-1.txz.
Installing package tcl-8.5.8-i486-1.txz:
PACKAGE DESCRIPTION:
# tcl (Tool Command Language)
#
# Tcl, developed by Dr. John Ousterhout, is a simple to use text-based
# script language with many built-in features which make it especially
# nice for writing interactive scripts.
#
# This is a version customized by nr that uses --disable-threads.
#
Executing install script for tcl-8.5.8-i486-1.txz.
Package tcl-8.5.8-i486-1.txz installed.

Package tcl-8.5.8-i486-1 upgraded with new package /tmp/tcl-8.5.8-i486-1.txz.

26 March, 2009

Slackware-current updates and Nvidia driver

I recently updated a desktop running Slackware-current to the latest packages released up to 24-Mar-2009. There were a few minor issues. The first is that, if using slackpkg to upgrade, I had to upgrade the findutils package before everything else or slackpkg would no longer work properly.

# slackpkg update
# slackpkg upgrade findutils
# slackpkg upgrade-all
The second was that I couldn't install the Nvidia driver for the new 2.6.28.8 kernel package because it was failing.
ERROR: The 'cc' sanity check failed:

The C compiler 'cc' does not appear able to
create executables. Please make sure you have
your Linux distribution's gcc and libc development
packages installed.
It turns out that gcc-4.3.3 in slackware-current depends on mpfr.
# slackpkg info mpfr

PACKAGE NAME: mpfr-2.3.1-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 348 K
PACKAGE SIZE (uncompressed): 930 K
PACKAGE DESCRIPTION:
mpfr: mpfr (Multiple-Precision Floating-Point Reliable Library)
mpfr:
mpfr: The MPFR library is a C library for multiple-precision floating-point
mpfr: computations with exact rounding (also called correct rounding).
mpfr: It is based on the GMP multiple-precision library.
mpfr: The main goal of MPFR is to provide a library for multiple-precision
mpfr: floating-point computation which is both efficient and has
mpfr: well-defined semantics. It copies the good ideas from the
mpfr: ANSI/IEEE-754 standard for double-precision floating-point arithmetic
mpfr: (53-bit mantissa).
mpfr:

# slackpkg install mpfr
After installing mpfr, I was able to compile the Nvidia module for the running kernel.

Finally, kdeinit4 was failing with an error about loading the libstreamanalyzer.so.0 and libqimageblitz.so shared libraries. I fixed this by installing strigi and qimageblitz.
# slackpkg info strigi

PACKAGE NAME: strigi-0.6.3-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 904 K
PACKAGE SIZE (uncompressed): 2570 K
PACKAGE DESCRIPTION:
strigi: strigi (fast and light desktop search engine)
strigi:
strigi: Strigi is a fast and light desktop search engine. It can handle a
strigi: large range of file formats such as emails, office documents, media
strigi: files, and file archives. It can index files that are embedded in
strigi: other files. This means email attachments and files in zip files
strigi: are searchable as if they were normal files on your harddisk.
strigi:
strigi: Homepage: http://strigi.sourceforge.net/
strigi:

# slackpkg info qimageblitz

PACKAGE NAME: qimageblitz-r900905-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 82 K
PACKAGE SIZE (uncompressed): 240 K
PACKAGE DESCRIPTION:
qimageblitz: QImageBlitz (Graphical effect and filter library for KDE4)
qimageblitz:
qimageblitz: Blitz is a graphical effect and filter library for KDE4.0 that
qimageblitz: contains many improvements over KDE 3.x's kdefx library
qimageblitz: including bugfixes, memory and speed improvements, and MMX/SSE
qimageblitz: support.
qimageblitz:

# slackpkg install strigi qimageblitz
After those minor issues, I had KDE4 up and running with the latest Nvidia driver.

25 January, 2008

Installing VMware on Slackware

As with many Unix users, I have tried many flavors, but these days there are a small number I actually use daily. The Linux distribution that I used to really get my feet wet when I first started was Slackware. Back when I first discovered Unix-like operating systems, I researched quite a few Linux distributions. One of the things that appealed to me about Slackware was, even back then, it was considered old-school. It seemed like a good choice if I wanted to learn as much as possible about everything under the hood, so to speak.

I still use it on a daily basis. Despite that, for some reason I had never installed VMware on a Slackware system. I don't believe VMware officially supports Slackware, and this can be seen pretty easily when you install it. The second question the installer asks is:

What is the directory that contains the init directories (rc0.d/ to rc6.d/)?
[/etc/init.d]

As many will know, the answer on Slackware is null. Slackware does not use SysV-style init by default, instead using a BSD-style layout for init scripts. The above question assumes that you are using a system that has a directory for each run level, which isn't the case on Slackware.

I assumed I could just create the empty directories and point the installer there without problems. A quick search confirmed my assumption. Using the simple for loop from that page:

$ sudo mkdir /etc/init.d
$ cd /etc/init.d
$ for i in {0,1,2,3,4,5,6}; do sudo mkdir rc$i.d; done
$ ls
rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d

Once the install was done, I removed the init.d directory and everything below it. One other note about the link is that I don't think you need to use the --compile switch with recent versions of VMware. It seemed to recognize that my Slackware generic kernel could not use the pre-built VMware modules. The only advantage to the --compile switch seems to be that it will skip the confirmation requests prior to compiling the modules, whereas running vmware-config.pl without the compile switch will ask for confirmation before compiling each module.

For the record, I was using slackware-current, kernel-generic-2.6.23.12, and VMware Workstation 6.0.2.

On a side note, I think my Slackware experience definitely translated well when I first tried FreeBSD. There are certainly plenty of differences, but it seems to me that going from Slackware to FreeBSD was a smaller learning curve than someone would have coming from a distribution like Ubuntu.