OpenSUSE Linux Rants

OpenSUSE Linux Tips, tricks, how-tos, opinions, and news

My Resume  -  My LinkedIn Profile

November 20, 2009

Enhancing openSUSE 11.2: Adding Repositories and Packages – Joe Brockmeier

by @ 9:58 am. Filed under General SUSE, How-To, SUSE Tips & Tricks

openSUSE Blog Linux Wallpapers

Zonker, you rock, brother. Joe ‘Zonker’ Brockmeier has provided us with a nice explanation of enhancing openSUSE 11.2. He talks about adding repositories and packages. It’s a little more user-friendly to new users than my quick summary: OpenSUSE Linux: Quick Zypper Tutorial.

Aimed at new users, he provides a nice detailed article on repositories, packages, and how to use zypper to manage them from the command-line.

Excerpt:

“So you’ve got that shiny new openSUSE 11.2 system up and running. Now what? The default repositories have plenty of software, but there’s much more for openSUSE in community and semi-official repositories that you might find useful.

“openSUSE comes with an enormous amount of software in the official repositories. But, sometimes you just need something that isn’t in the default release. Either because the package isn’t offered through the official repos, or because you want to track software that’s ahead of the current release.”

Take a look at Enhancing openSUSE 11.2: Adding Repositories and Packages

November 16, 2009

Linux Display Managers for fun and profit

by @ 10:53 am. Filed under General Linux, SUSE Tips & Tricks, terminal

When you start up Linux on your box, generally you are taken to a graphical login screen (unless, of course, you have configured things differently). This graphical login screen is called the display manager.

Would you like to check out some different display managers in Linux? There are about 4 that I have been playing around with: xdm, gdm, kdm, wdm

To take a look at the differences, and see which one you like, install them with your package manager. With OpenSUSE, this is yast or zypper.

The commandline way to do this is simple:

For OpenSUSE 11.2

[1004][root@dev:/home/scott]$ zypper in gdm kdm wdm xdm

To see which one you like, edit the /etc/sysconfig/displaymanager file. Look for this section:

## Type:        string(kdm,kdm3,kdm4,xdm,gdm,wdm,console)
## Default:     ""
#
# Here you can set the default Display manager (kdm/xdm/gdm/wdm/console).
# all changes in this file require a restart of the displaymanager
#
DISPLAYMANAGER="kdm4"

You’ll notice that the first couple of lines tell you what to put in for the display manager you want to use (kdm,kdm3,kdm4,xdm,gdm,wdm,console). Put in different ones and see what floats your boat. When you get it how you like it, stop.

For OpenSUSE 11.1

[1004][root@dev:/home/scott]$ zypper in gdm kde4-kdm wdm

I didn’t see xdm available on 11.1, but I could be up in the night.

To see which one you like, edit the /etc/sysconfig/displaymanager file. Look for this section:

## Type:        string(kdm,kdm3,kdm4,xdm,gdm,wdm,console)
## Default:     ""
#
# Here you can set the default Display manager (kdm/xdm/gdm/wdm/console).
# all changes in this file require a restart of the displaymanager
#
DISPLAYMANAGER="kdm4"

You’ll notice that it tells you what to put in for the display manager you want to use (kdm,kdm3,kdm4,xdm,gdm,wdm,console). Take a look at them, see which one suits your fancy, and use the one that makes your heart tingle.

G’day.

November 1, 2009

OpenSUSE Linux: Quick Zypper Tutorial

by @ 1:21 am. Filed under bash, command-line, SUSE Tips & Tricks

OpenSUSE Linux provides a command-line method of managing repositories and packages. This tool is called zypper. The following is a basic tutorial by example of how to use zypper.

Repository Management

To list repositories:

[1342][root@dev:/home/scott]$ zypper repos
#  | Alias             | Name                  | Enabled | Refresh
---+-------------------+-----------------------+---------+--------
1  | Enlightenment CVS | Enlightenment CVS     | Yes     | Yes    
2  | OpenSUSE_11.1_ISO | OpenSUSE 11.1 ISO     | Yes     | No     
3  | Packman           | Packman               | Yes     | Yes    
4  | Window_Managers   | Window Managers       | Yes     | Yes    
5  | XFCE4             | XFCE4                 | Yes     | Yes    
6  | aterm             | aterm                 | Yes     | Yes    
7  | home:danci1973    | home:danci1973        | Yes     | Yes    
8  | home:dauphin      | home:dauphin          | Yes     | Yes    
9  | home:jnelson-suse | home:jnelson-suse     | Yes     | Yes    
10 | mozilla           | mozilla               | Yes     | Yes    
11 | openSUSE 11.1-0   | openSUSE 11.1-0       | Yes     | Yes    
12 | repo-debug        | openSUSE-11.1-Debug   | No      | Yes    
13 | repo-non-oss      | openSUSE-11.1-Non-Oss | Yes     | Yes    
14 | repo-source       | openSUSE-11.1-Source  | No      | Yes    
15 | repo-update       | openSUSE-11.1-Update  | Yes     | Yes    
[1402][root@dev:/home/scott]$

To add a repository (we’re going to use Packman as an example):

[1341][root@dev:/home/scott]$ zypper addrepo "http://packman.unixheads.com/suse/11.1/" Packman
Adding repository 'Packman' [done]
Repository 'Packman' successfully added
Enabled: Yes
Autorefresh: No
URI: http://packman.unixheads.com/suse/11.1/

[1341][root@dev:/home/scott]$ 

To turn on autorefresh, because it’s disabled by default (again, with Packman):

[1341][root@dev:/home/scott]$ zypper modifyrepo -r Packman
Autorefresh has been enabled for repository 'Packman'.
[1342][root@dev:/home/scott]$

To refresh a repo manually:

[1342][root@dev:/home/scott]$ zypper refresh -r Packman
Retrieving repository 'Packman' metadata [done]
Building repository 'Packman' cache [done]
Specified repositories have been refreshed.
[1342][root@dev:/home/scott]$

Leave out the “-r” and leave off the name of the repo if you want to refresh all of them.

To remove a repository:

[1337][root@dev:/home/scott]$ zypper rr Packman
Removing repository 'Packman' [done]
Repository 'Packman' has been removed.
[1337][root@dev:/home/scott]$ 

Package Management

To search for a package (id3v2, in this example):

[1224][root@dev:/home/scott]$ zypper search id3v2
Loading repository data...
Reading installed packages...

S | Name  | Summary                              | Type   
--+-------+--------------------------------------+--------
  | id3v2 | A Command Line Editor for ID3V2 Tags | package
[1229][root@dev:/home/scott]$

To get information on a package (again, id3v2):

[1229][root@dev:/home/scott]$ zypper info id3v2
Loading repository data...
Reading installed packages...


Information for package id3v2:

Repository: openSUSE 11.1-0
Name: id3v2
Version: 0.1.11-77.60
Arch: x86_64
Vendor: openSUSE
Installed: No
Status: not installed
Installed Size: 79.0 K
Summary: A Command Line Editor for ID3V2 Tags
Description: 
ID3 tags are found in MP3 files. They canstore information about what band recorded the song, the song name, and more.

ID3V1 tags are seriously deficient as to the kind of and length ofinformation that they can store. This is a tool for editing ID3V2tags in Linux.


[1333][root@dev:/home/scott]$ 

To install a package:

[1333][root@dev:/home/scott]$ zypper install id3v2
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  id3v2 


Overall download size: 30.0 K. After the operation, additional 79.0 K will be used.
Continue? [YES/no]: 
Retrieving package id3v2-0.1.11-77.60.x86_64 (1/1), 30.0 K (79.0 K unpacked)
Retrieving: id3v2-0.1.11-77.60.x86_64.rpm [done]          
Installing: id3v2-0.1.11-77.60 [done]
[1334][root@dev:/home/scott]$

To remove a package:

[1334][root@dev:/home/scott]$ zypper remove id3v2
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:
  id3v2 


After the operation, 79.0 K will be freed.
Continue? [YES/no]: 
Removing id3v2-0.1.11-77.60 [done]
[1336][root@dev:/home/scott]$

These are some common zypper commands that will help you manage your repositories and packages from the command-line.

October 28, 2009

Slick Linux Virtual Terminal: aterm

by @ 1:32 am. Filed under command-line, Linux tips, SUSE Tips & Tricks, terminal

In the search for a full weight loss program for my window manager (I’m switching from KDE 3.5 to XFCE4), it became clear that another terminal would have to replace Konsole. After 11 full minutes of considerable thought, agonizing contemplation, deliberation and extensive research, aterm became the obvious choice.

aterm looked interesting to me because it has a small memory footprint. Konqueror takes up about 7 times the RAM that aterm does, while xterm takes over twice the RAM that aterm does. aterm also has very little dependencies. Additionally, it supports pseudo-transparencies, while remaining very responsive and quick.

The first thing you want to do is install aterm. This does not appear to be available on OpenSUSE 11.1 by default. But just add the following repo:

http://download.opensuse.org/repositories/home:/-miska-:/Release/openSUSE_11.1

Add the repo as root like this:

[1049][root@laptop:~]$ zypper addrepo http://download.opensuse.org/repositories/home:/-miska-:/Release/openSUSE_11.1 aterm
Adding repository 'aterm' [done]
Repository 'aterm' successfully added
Enabled: Yes
Autorefresh: No
URI: http://download.opensuse.org/repositories/home:/-miska-:/Release/openSUSE_11.1

[1049][root@laptop:~]$

Refresh the repo:

[1049][root@laptop:~]$ zypper refresh aterm
Retrieving repository 'aterm' metadata [done]
Building repository 'aterm' cache [done]
Specified repositories have been refreshed.
[1050][root@laptop:~]$

Install aterm:

[1112][root@dev:/home/scott]$ zypper install aterm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  AfterStep_applets_all 


Overall download size: 310.0 K. After the operation, additional 1.1 M will be used.
Continue? [YES/no]: 
Retrieving package AfterStep_applets_all-070412-5.13.x86_64 (1/1), 310.0 K (1.1 M unpacked)
Retrieving: AfterStep_applets_all-070412-5.13.x86_64.rpm [done]         
Installing: AfterStep_applets_all-070412-5.13 [done]
[1112][root@dev:/home/scott]$ 

Now, run aterm in a terminal window or something to make sure it’s installed.

On to the configuration (which is the cool part, really).

First, determine which font you want to use by running xfontsel. It opens up a window where you can fine-tune the font you want aterm to use.

Then, you’ll want to set up your configuration file. I use .Xresources although there are others you can use.

Copy and paste this into your .Xresources file, and then adjust as necessary:

aterm*font: -*-fixed-medium-r-*-*-18-*-*-*-*-*-iso8859-*
aterm*font1: -*-*-*-*-*-*-2-*-*-*-*-*-*-*
aterm*font2: -misc-fixed-*-r-normal-*-8-*-*-*-*-*-iso8859-*
aterm*font3: -b&h-lucidatypewriter-bold-*-*-*-12-*-*-*-*-*-*-*
aterm*font4: -*-screen-bold-r-normal-*-16-*-*-*-*-*-iso8859-*
aterm*font5: -*-lucidatypewriter-medium-*-*-*-18-*-*-*-*-*-*-*
aterm*font6: -*-lucidatypewriter-medium-*-*-*-20-*-*-*-*-*-*-*
aterm*font7: -dec-terminal-bold-r-normal-*-14-*-*-*-*-*-iso8859-*

aterm*background: black
aterm*foreground: white
aterm*pointerColor: red
aterm*pointerColorBackground: black
aterm*cursorColor: blue
aterm*internalBorder: 3
aterm*loginShell: true

! Do you want a scrollbar?
aterm*scrollBar: true
aterm*scrollKey: true

! How many lines do you want to save in the buffer?
aterm*saveLines: 32767
aterm*multiClickTime: 250

! Do you want transparency?
aterm*transparent: true

! Do you want transparency in the scrollbar?
aterm*transpscrollbar: true

! How much transparency do you want (in percent)?
aterm*shading:20

!aterm*tintingType: true
!aterm*tinting: #a07040

! How many characters wide and tall should your window be?
aterm*geometry: 80x40

! Do you want a visual bell rather than an audio bell?
aterm*visualBell: true

Hopefully, it’s apparent that you can use exclamation points for comments.

Everything in this sample .Xresources config file should be fairly self-explanatory.

aterm takes many of the same configuration directives as xterm. So if you see an xterm directive you want aterm to use, throw it in the .Xresources file and reload it. You reload the .Xresources file with the following command:

[1058][scott@dev:~]$ xrdb -merge .Xresources
[1058][scott@dev:~]$ 

If you are running that command in an open aterm window, you will have to close the window and re-run aterm.

aterm is very quick and responsive, looks nice, and doesn’t take up too much memory. Take a look at it, play around with it, and enjoy it.

October 22, 2009

OpenSUSE Linux: When 1-Click Install Bites the Dust

by @ 8:38 am. Filed under SUSE Tips & Tricks

OpenSUSE Linux 1-Click Install

In OpenSUSE Linux, we have a wonderful thing called One-Click Install. This is a marvelous thing for new users. I love it to death, and care for it as I would my own child. Almost everyone knows that this is very cool except for maybe Christer, as he is not a believer (nuttin but love bro, loved your presentation @ UTOSC). That said, what happens when it stops working or gets broken?

Use Windows.

Let’s head over to the OpenSUSE Build Service. Search for something cool like the fluxbox window manager. The results come up, and you click on the 1-Click Install.

You should see something like this:

1-Click Install Dialog Working

However, if it is broken, you will not see the “YaST Meta Package Handler (default)” in the OPEN WITH radio button drop-down.

You may see something like this:

1-Click Install Dialog Broken

The first thing to do is tear your hair out. If you don’t have any, turn to the closest person to you (I do not recommend a spouse unless you want to spend the rest of your life on the couch).

The first thing to do is to click CANCEL. Then, look right above the 1-Click Install button. There is a link in gray:

1-Click Install Repo Link

Click that bad boy. You are taken to a really scary-looking page like this:

Repository Index

Totally no worries here. Copy everything in the address bar:

Repository Address

Pop open a terminal window, become root, and use zypper to add the repository. Then refresh it, like so:

[0917][scott@suse-desktop:~]$ su
Password:
[0917][root@suse-desktop:/home/scott]$ zypper addrepo "http://download.opensuse.org/repositories/X11:/windowmanagers/openSUSE_11.1/" windowmanagers
Adding repository 'windowmanagers' [done]
Repository 'windowmanagers' successfully added
Enabled: Yes
Autorefresh: No
URI: http://download.opensuse.org/repositories/X11:/windowmanagers/openSUSE_11.1/

[0917][root@suse-desktop:/home/scott]$ zypper refresh windowmanagers
Retrieving repository 'windowmanagers' metadata [done]
Building repository 'windowmanagers' cache [done]
Specified repositories have been refreshed.
[0917][root@suse-desktop:/home/scott]$

Now, you can search for fluxbox and it will find it in your repositories, because you just added the one with fluxbox in it:

[0919][root@suse-desktop:/home/scott]$ zypper search fluxbox
Loading repository data...
Reading installed packages...

S | Name    | Summary                   | Type
--+---------+---------------------------+-----------
  | fluxbox | The fluxbox windowmanager | package
  | fluxbox | The fluxbox windowmanager | srcpackage
[0919][root@suse-desktop:/home/scott]$

If you’d like to install it, go for it, baby. No holds barred:

[0919][root@suse-desktop:/home/scott]$ zypper in fluxbox
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  fluxbox


Overall download size: 920.0 K. After the operation, additional 3.6 M will be used.
Continue? [YES/no]:
Retrieving package fluxbox-1.1.1-1.2.i586 (1/1), 920.0 K (3.6 M unpacked)
Retrieving: fluxbox-1.1.1-1.2.i586.rpm [done (236.8 K/s)]
Installing: fluxbox-1.1.1-1.2 [done]
[0920][root@suse-desktop:/home/scott]$

Houston, we have landed. Now, go enjoy your new package. This method should work with virtually any package where the 1-Click install fails.

July 30, 2009

Linux appliances made easy with SUSE Studio

by @ 8:25 am. Filed under SUSE News, SUSE Tips & Tricks, sweet tools

Linux appliances made easy with SUSE

¡Por fin! It’s about time they did something like this with OpenSUSE Linux. Uses for this are infinite. What a fantastically cool concept.

From the site, “Novell has launched a new service called SUSE Studio that makes it easy to build software appliances. Ars gives it a spin and find it’s an excellent tool for building virtual appliances.”

Now honestly, who couldn’t use that?

Check this out: “Novell has launched a new Web service called SUSE Studio that simplifies the process of building Linux-based software appliances. It provides a convenient interface for creating custom versions of Novell’s SUSE Linux distribution with specialized configurations. The service is part of Novell’s broader SUSE Appliance Program initiative.”

“Enterprise software deployment comes with a lot of serious technical challenges. Getting a complex piece of server software up and running on backend infrastructure often requires system administrators to wrestle with dependencies and configuration issues. Software appliances are increasingly viewed as a compelling solution to this problem.”

“A software appliance is a preconfigured stack that includes a software program and its dependencies bundled with a minimal operating system image that can get the program up and running with the smallest possible resource footprint. This concept is often referred to as “Just Enough Operating System” (JeOS).”

“SUSE Studio allows users to build software appliances on top of SUSE Enterprise Linux or OpenSUSE. It offers several templates that can be used as a starting point, including a minimal JeOS template, a server template, a minimal X11, KDE, and GNOME templates. After selecting a base template, users can customize it and add additional software.”

The versatility of Linux never ceases to blow my mind. I mean, to each their own, but if you are looking for the X-11 of consumer-level operating systems, Linux stands up to the test, tell you what (tell your mom, too).

Enough of my yammering about this new OpenSUSE project. Take a look at the screen shots and full story:

Linux appliances made easy with SUSE

May 21, 2009

OpenSUSE Linux: Creating Self-Signed SSL Certificates

by @ 2:54 pm. Filed under Linux tips, security, SUSE Tips & Tricks

Originally written Jun 2, 2008, and updated on May 21, 2009

Overview

At some point or another, you’ll likely end up needing an SSL certificate for a Web site somewhere along the line. For a commercial site, your hosting provider can or will help you get this all squared away. This article is not for people in that situation.

What we’re doing here will be to create our own Certificate Authority. Then, we’ll create our own server key and a signing request. Then, we’ll sign our own certificate using the key and certificate from our own Certificate Authority. In other words, we’re not just going to create an SSL certificate, but we’re going to sign that bad boy, too.

This is useful for personal websites that need a little security, or when you’re waiting for your real cert from a real Certificate Authority. Perhaps you need it for transmitting data from an external server to your Intranet. Or perhaps you need it in any of the three hundred thousand seven hundred forty-two other situations that may arise.

Certificate Authority

The first thing that you’ll need is root access to the server. SSH in and head somewhere secure like /root.

Next, we’ll go ahead and generate our own Certificate Authority key. In this step, we are impersonating someone like Verisign or Thawte. Well, not impersonating, but we are going to do the same thing for ourselves that they would normally do.

To create our key, we’ll run this command:

openssl genrsa -des3 -out ca.key 4096

When we do that, it looks something like this:

[1257][root@mail:~/cert]$ openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
...............................................................................................................................++
.................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key: [enter a pass phrase here for the CA key]
Verifying - Enter pass phrase for ca.key: [verify the same pass phrase here]
[1258][root@mail:~/cert]$ 

Note that those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Next, we’ll need to use that key to create a certificate. Before we do this, the information that you will enter here is NOT the information you will enter later for your own server. Remember, we are emulating a Certificate Authority here. When we generate our server certificate, we will put in the real information which must differ from what is here. With that, let’s whip out the certificate. Notice that we are making it good for 3650 days, or 10 years. Adjust to your taste. So let’s make the cert, now. This is done with the following command:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

And doing this may resemble something like this:

[1306][root@mail:~/cert]$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:WA
Locality Name (eg, city) []:Redmond
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Microsoft Corporation
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.microsoft.com
Email Address []:bill.gates@microsoft.com
[1307][root@mail:~/cert]$ 
Our Server Key and CSR

Next up on the list is to create a key that corresponds to our server. The first one we made was for the Certificate Authority. This one will be generated by and for our own server. We will do that with this command:

openssl genrsa -des3 -out server.key 4096

The output should look familiar:

[1310][root@mail:~/cert]$ openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
................................++
....++
e is 65537 (0x10001)
Enter pass phrase for server.key: [enter a pass phrase here for our server key]
Verifying - Enter pass phrase for server.key: [verify the same pass phrase here]
[1313][root@mail:~/cert]$ 

Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.

Now… let’s see… oh yeah. Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?

To create the CSR, we do this:

openssl req -new -key server.key -out server.csr

Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. And so we do:

[1313][root@mail:~/cert]$ openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:UT
Locality Name (eg, city) []:Eagle Mountain
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Suse Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.suseblog.com
Email Address []:my-address@suseblog.com [put in your real email address here]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[1323][root@mail:~/cert]$ 
Sign the Certificate

Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely.

The command we’re going to run looks like this:

openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

And when we run it, we see something hopefully resembling this:

[1326][root@mail:~/cert]$ openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=US/ST=UT/L=Eagle Mountain/O=Suse Blog/CN=www.suseblog.com/emailAddress=my-address@suseblog.com
Getting CA Private Key
Enter pass phrase for ca.key: [enter the CA pass phrase from above here]
[1332][root@mail:~/cert]$ 
Generate server.key That Won’t Prompt for Password

Now, we have a little problem. Our server.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

When we run these commands, here’s our output:

[1354][root@mail:~/cert]$ openssl rsa -in server.key -out server.key.insecure
Enter pass phrase for server.key: [enter the pass phrase here for our server key from above]
writing RSA key
[1354][root@mail:~/cert]$ mv server.key server.key.secure
[1354][root@mail:~/cert]$ mv server.key.insecure server.key
[1354][root@mail:~/cert]$
Placing the Files

At this stage, you should now have a bunch of files. These, in fact:

[1354][root@mail:~/cert]$ ll
total 32
drwxr-xr-x  2 root root 4096 2008-06-02 13:54 .
drwx------ 10 root root 4096 2008-06-02 13:35 ..
-rw-r--r--  1 root root 2529 2008-06-02 13:07 ca.crt [CA certificate]
-rw-r--r--  1 root root 3311 2008-06-02 12:58 ca.key [CA key]
-rw-r--r--  1 root root 2049 2008-06-02 13:32 server.crt [our server certificate]
-rw-r--r--  1 root root 1748 2008-06-02 13:23 server.csr [our server signing request]
-rw-r--r--  1 root root 3243 2008-06-02 13:54 server.key [our password-less server key]
-rw-r--r--  1 root root 3311 2008-06-02 13:13 server.key.secure [our passworded server key]
[1355][root@mail:~/cert]$

Just having them doesn’t get us anywhere, so let’s get them installed. First, we are going to change some permissions, because we don’t want just anyone having access to these files. To apply the appropriate permissions, run this:

chmod 0600 server.key.secure server.key server.csr server.crt

Now, here’s where things depend on the distribution that you are using. I will describe what I am doing so that if you are not on OpenSUSE, you will still be able to get this working.

In OpenSUSE, the apache2 config directory is located at /etc/apache2. Underneath that, there are a handful of directories. The three we care about are /etc/apache2/ssl.crt, /etc/apache2/ssl.csr, and /etc/apache2/ssl.key. The server.crt needs to be moved to /etc/apache2/ssl.crt. The server.csr file needs to be moved to /etc/apache2/ssl.csr. And the server.key file needs to be moved to /etc/apache2/ssl.key:

[1348][root@mail:~/cert]$ mv server.key /etc/apache2/ssl.key/server.key
[1349][root@mail:~/cert]$ mv server.crt /etc/apache2/ssl.crt/server.crt
[1349][root@mail:~/cert]$ mv server.csr /etc/apache2/ssl.csr/server.csr
[1349][root@mail:~/cert]$

Yep, pretty complex stuff, moving files.

Now, we need to make a handful more edits to some files, and we’re just about there.

System Configuration

First thing is to edit /etc/sysconfig/apache2. Search through that file for the directive called APACHE_MODULES. Make sure you see ‘ssl’ in there. If not, add it. Then, search through the file and find APACHE_SERVER_FLAGS. Make sure it has ‘SSL’ in it. If not, add it. Save and close the file.

You can also manage apache’s modules with the ‘a2enmod’ command. To view the list of loaded modules, run ‘a2enmod -l’.

Next, open up the config file that tells apache2 which ports to listen on. In OpenSUSE, this file is /etc/apache2/listen.conf. Rip that bad boy open. You will see the following line:

Listen 80

Add a new line for port 443, our HTTPS port, so that it looks like this:

Listen 80
Listen 443

Then, look for the following line:

NameVirtualHost *:80

Add a new line for port 443, our HTTPS port, so that it looks like this:

NameVirtualHost *:80
NameVirtualHost *:443

Save and quit.

Virtual Host Configuration

In OpenSUSE, it’s really easy to have virtual hosts on a machine. I have like 10 on mine. One of them is my blog, www.suseblog.com. Well, to make this easy, in OpenSUSE, the virtual domain configuration files are located in /etc/apache2/vhosts.d, each with their own name. My www.suseblog.com configuration file is called suseblog.conf. To set up SSL for this virtual host, just duplicate the file and give it another name. In my case, I named it ssl-suseblog.conf.

Now, we’re going to open up that file and add like 4 lines to it. No sweat.

At the top of the file, there is a line that looks like this:

<VirtualHost *:80>

Change the port from 80 to 443, so it looks like this:

<VirtualHost *:443>

Then, go down a ways and add these lines:

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

Save and quit on that one, too.

Configure Firewall

We can configure this thing perfectly, but if the firewall doesn’t know to let traffic through, we will not have HTTPS access to the server. Let’s check the firewall really quick to make sure.

Fire up YAST. Go to the Security & Users option on the right, and select FIREWALL from the left. If you do not have a firewall running on the machine, you can just exit now. If you do, you will need to go to ALLOWED SERVICES. In the SERVICES TO ALLOW drop-down on the right, select HTTPS Server. Then click ADD. Then click NEXT, and finally FINISH. You should now have port 443 opened for HTTPS business.

Now, let’s go ahead and restart apache and enjoy our new self-signed self-generated SSL cert on our HTTPS service:

[1426][root@mail:/etc/apache2]$ /etc/init.d/apache2 restart
Syntax OK
Shutting down httpd2 (waiting for all children to terminate)          done
Starting httpd2 (prefork)                                             done
[1427][root@mail:/etc/apache2]$ 
Conclusion

Well, we’ve concluded. Enjoy.

More info on the mod_ssl page

December 16, 2008

OpenSUSE 11.1 Access Secrets [pic]

by @ 9:50 pm. Filed under SUSE releases, SUSE Tips & Tricks

OpenSUSE Linux 11.1

OK, so we’ve been chatting a bit about the upcoming release of OpenSUSE 11.1. If we throw an eyeball at the official OpenSUSE.org server, the newest thing available from the official OpenSUSE.org server is not a GM. When it is a GM, DO NOT DOWNLOAD IT FROM THAT SERVER. That only hogs bandwidth that they use to transfer it to the mirrors. Wait about 4 hours, and then pick your favorite mirror and pull it down from there.

But unless I get a personal email from Stephan Kulow or Andreas Jaeger or Michael Loeffler, stating otherwise, I’m reasonably sure that the OpenSUSE 11.1 GM is not publicly available, yet.

However, now you know how to check for yourself for sure when it has been released. But if I catch you downloading from there the minute they put it on there, so help me….

Tell you what, though, if you really want to get some wicked screenshots from how OpenSUSE 11.1 will look, hop on your nearest moped and head over to http://news.opensuse.org/. There are previews of tons of stuff related to OpenSUSE 11.1, including this:

Click for larger version

So we know the GM exists, but it’s the “Where’s Waldo?” element of it that still has my OCD in overdrive.

December 15, 2008

Linux + Cinelerra = some pretty entertaining videos

by @ 1:03 pm. Filed under My Opinion, SUSE Tips & Tricks, sweet tools

Linux Video Editing with Cinelerra

I have another Cinelerra animatic storyboarding assignment done. We had to convey a story to the audience that would persuade them to purchase our product. Mine went a little overboard, but everyone thought it was a hoot:


Click image to download Ogg Theora Video
Here’s a WMV if you don’t do Ogg Theora

There was a time when I would rather take a 2×4 full of rusty nails and jam it through my neck sideways than try and use Cinelerra, but the more obstinately I mercilessly force myself to keep using it, the cooler the stuff I am able to do. Now, don’t confuse that with me having delusions of talent. It’s just that I can find the cooler features of the program.

For what that’s worth, take a gander at the video, and see if you get the joke. Have a good one.

June 12, 2008

How many ways can you install an RPM in OpenSUSE Linux?

by @ 7:02 am. Filed under command-line, How-To, SUSE Tips & Tricks
Introduction

Package management in OpenSUSE in recent years has had its share of challenges. In OpenSUSE 10.1, the package management was an epic trainwreck. Package management in OpenSUSE 10.3 is as good as that was bad. There are various types of speed improvements. Some of them huge. There is some caching of the repository package info. Progress bars so the user knows what’s going on. All sorts of goodness.

But I wanted to see how many ways I could install a package on OpenSUSE 10.3 (and 11.0, for that matter) without any help from any third-party package management tools that don’t come stock on a fresh OpenSUSE install. Like no apt, yum, smart, etc. Just using the package management tools that come on the fresh install, how many ways can one install a package? There’s a method to this madness, too. You never know under what circumstances you’ll have what access to the machine you’re working on, especially if it is remote. One of the mantras of Linux pros is that there is four billion ways to skin a cat. OK, so I made that up. It’s good to know many ways of doing the same thing, though.

Especially if we want to automate something. If we do it one way, maybe it requires human interaction. If we do it a different way, no human interaction is required, and thus, we can automate that process.

OK, without any more excessive yammer, let’s take a look, shall we?

RPM Installation Methods

1. Use YAST – Let’s get the obvious one out of the way. Click on the YAST icon, put in your root password. In the window that appears, select SOFTWARE from the left, and SOFTWARE MANAGEMENT on the right. At some point, the YAST Package Management window appears. Search for the desired package, click ACCEPT. Approve any additional necessary packages. YAST installs everything, and asks if you want to install or remove more packages. Say no, and you’re done.

This is the classic way to install packages in OpenSUSE using YAST. One benefit is that it does a good job of resolving dependencies for you. One possible drawback is that it reauires all kinds of human interaction. So there’s our first way.

2. Use zypper – This is a powerful command-line tool used in OpenSUSE much in the same way we might use something like apt-get. To see all the ways you can use this tool, run zypper –help from a command line:

[2318][root@linux:/]$ zypper --help
  Options:
        --help, -h              Help.
        --version, -V           Output the version number.
        --quiet, -q             Suppress normal output, print only error messages.
        --verbose, -v           Increase verbosity.
        --terse, -t             Terse output for machine consumption.
        --table-style, -s       Table style (integer).
        --rug-compatible, -r    Turn on rug compatibility.
        --non-interactive, -n   Don't ask anything, use default answers automatically.
        --no-gpg-checks         Ignore GPG check failures and continue.
        --root, -R <dir>        Operate on a different root directory.

  Commands:
        help, ?                 Help
        shell, sh               Accept multiple commands at once
        install, in             Install packages or resolvables
        remove, rm              Remove packages or resolvables
        search, se              Search for packages matching a pattern
        repos, lr               List all defined repositories.
        addrepo, ar             Add a new repository
        removerepo, rr          Remove specified repository
        renamerepo, nr          Rename specified repository
        modifyrepo, mr          Modify specified repository
        refresh, ref            Refresh all repositories
        patch-check, pchk       Check for patches
        patches, pch            List patches
        list-updates, lu        List updates
        xml-updates, xu         List updates and patches in xml format
        update, up              Update installed resolvables with newer versions.
        info, if                Show full information for packages
        patch-info              Show full information for patches
        source-install, si      Install a source package
[2319][root@linux:/]$

To install a package from the command line using zypper, you’ll do that this way:

[2321][root@linux:/]$ zypper install bzflag
* Reading repository 'openSUSE-10.3-Updates' cache
* Reading repository 'openSUSE-10.3-OSS-KDE 10.3' cache
* Reading repository 'Jpackage' cache
* Reading repository 'Main Repository (NON-OSS)' cache
* Reading repository 'Eric Lavar - Germany' cache
* Reading repository 'Main Repository (OSS)' cache
* Reading installed packages [100%]


The following NEW package is going to be installed:
  bzflag

Overall download size: 10.8 M. After the operation, additional 15.0 M will be used.
Continue? [yes/no]: yes
Downloading package bzflag-2.0.8-78.x86_64, 10.8 M (15.0 M unpacked)
Downloading: media
* Downloading [100%]
Downloading: bzflag-2.0.8-78.x86_64.rpm
* Downloading [100%]
* Installing: bzflag-2.0.8-78 [100%]
[2323][root@linux:/]$

It resolves all dependencies, and installs everything it needs. Great way to do things without so much human interaction. There are even flags that will allow us to omit human interaction entirely (–non-interactive and –no-gpg-checks). Very nice.

3. Use the rpm command – Every once in awhile, there is a package that YAST cannot find in the available repositories. When this happens, I head over to one of three places: rpmseek.com, Rpmfind, or pbone.net. In almost every case, I can find an RPM that was built for whatever version of OpenSUSE that I am using on that particular box. I just download the RPM in question, and install it with the rpm command. Many people suggest doing this in the following manner:

[2215][scott@linux:~]$ rpm -Uvh [full path to RPM here]

This is one of the possibly more difficult ways to install an RPM. Not because it’s a difficult command, but because it doesn’t resolve dependencies. If there are dependencies, you get to resolve those babies yourself. It’s possible, but I would definitely prefer a poke in the eye with a sharp stick.

4. 1-Click Install – Tell you what, one of the coolest things that OpenSUSE has come up with thus far is the 1-Click Install. At first, I thought it was an April Fool’s Joke. But realizing it wasn’t April, I decided to give it a try. To see how cool this is, head over to the OpenSUSE Build Service. Search for a package like kopete. Scroll through the results. When you find the one you want to install, click on the “1-Click Install” button off to the right side. You’ll have to verify some things and provide your root password, but other than that, it is virtually hands-off installation of the package. Hands-down easiest way to install packages in OpenSUSE.

5. Install with YAST from custom installation repository – Sometimes, you will have an rpm that you want installed, but cannot find it in YAST. You can download it and try to install it with rpm. The problem is that it has 12 dependencies. What then? Switch distributions to something more sensible? No way, we’ll just take the easy way out. Create our own repository and point YAST to that. This process is very simple.

Install the createrepo package. Then, create a directory to be used as the repository. Dump the RPM in there. Then, run the createrepo command on that directory. For example, make a directory called /my_inst_src. Throw your RPM (as hard as you can) into that folder. Then, create the repository with this command:

[2246][root@linux:/home/scott]$ createrepo /my_inst_src
1/1 - pidgin-2.4.2-5.1.i586.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata
[2247][root@linux:/home/scott]$

Then, just add that directory as an installation source in YAST=>SOFTWARE=>SOFTWARE REPOSITORIES.

Finally, go into YAST=>SOFTWARE=>SOFTWARE MANAGEMENT and search for the RPM you placed into your new repository. You should be able to find and install it easily. The great part here is that YAST should be able to resolve the package dependencies.

Yes, there are a few steps involved here. However, you can take this concept and apply it to an entire network of desktop or server machines. Pick a repository server on your network and create your own repository on it. Then, export that repo via NFS to the rest of the network. Next, just add that repository to the other machines on the network. The great part is that you only have to add the repository to each of the other machines once. But then, instant access to install that package on any of those boxes. This particular solution has been very helpful for me on several occasions.

6. Install with zypper from custom installation repository – Same thing as the previous method. We download a stand-alone RPM that has many dependencies. So the approach will be similar. Install createrepo, make a repository directory, and put your RPM in there. Use createrepo to build your repository as demonstrated above.

Then, instead of YAST, go ahead and add your new repository using the zypper command, like so:

[2308][root@linux:/home/scott]$ zypper addrepo /my_inst_src "My Installation Source"
* Adding repository 'My Installation Source'
Repository 'My Installation Source' successfully added:
Enabled: Yes
Autorefresh: Yes
URL: dir:///my_inst_src
[2309][root@linux:/home/scott]$

Make sure it was installed properly, again using zypper:

[2258][root@linux:/home/scott]$ zypper repos
# | Enabled | Refresh | Type   | Alias                                                             | Name
--+---------+---------+--------+-------------------------------------------------------------------+-----------------------------------------------------------
1 | Yes     | Yes     | rpm-md | openSUSE-10.3-Updates                                             | openSUSE-10.3-Updates
2 | Yes     | No      | yast2  | openSUSE-10.3-OSS-KDE 10.3                                        | openSUSE-10.3-OSS-KDE 10.3
3 | No      | Yes     | NONE   | http://download.opensuse.org/distribution/10.3/repo/debug/        | http://download.opensuse.org/distribution/10.3/repo/debug/
4 | Yes     | Yes     | rpm-md | Jpackage                                                          | Jpackage
5 | Yes     | Yes     | yast2  | http://download.opensuse.org/distribution/10.3/repo/non-oss/      | Main Repository (NON-OSS)
6 | Yes     | Yes     | rpm-md | Eric_Lavar_-_Germany                                              | Eric Lavar - Germany
7 | Yes     | Yes     | rpm-md  | My Installation Source                                            | My Installation Source
8 | Yes     | Yes     | yast2  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | Main Repository (OSS)
[2259][root@linux:/home/scott]$

There it is, highlighted in red. Rock on, now we can make sure zypper finds our new package, thusly:

[2309][root@linux:/home/scott]$ zypper search pidgin
Refreshing 'My Installation Source'
repomd.xml is unsigned, continue? [yes/no]: yes
* Building repository 'My Installation Source' cache
* Reading installed packages [100%]

S | Repository                                                        | Type    | Name                   | Version    | Arch
--+-------------------------------------------------------------------+---------+------------------------+------------+-------
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin                 | 2.1.1-13   | i586
i | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin                 | 2.1.1-13   | x86_64
v | My Installation Source                                            | package | pidgin                 | 2.4.2-10.1 | x86_64
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-bot-sentry      | 1.1.0-45   | i586
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-bot-sentry      | 1.1.0-45   | x86_64
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-bot-sentry-lang | 1.1.0-45   | i586
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-bot-sentry-lang | 1.1.0-45   | x86_64
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-devel           | 2.1.1-13   | i586
  | http://download.opensuse.org/repositories/openSUSE:10.3/standard/ | package | pidgin-devel           | 2.1.1-13   | x86_64
[2309][root@linux:/home/scott]$ 

The one we’re looking for is highlighted in red. Looks like we’re ready to go ahead and install the application:

[2313][root@linux:/home/scott]$ zypper in pidgin

If the package is so brand-new that it has dependencies that are unresolvable, obviously you’ll have problems. But for many common packages, this method works great.

As a side note, you can also set your machines up so that you don’t even need the discs to install packages. Put the DVD ISO on your machine and you can put that into YAST as an installation source. Disable the source that uses the local optical drive. Then, it will pull packages from the ISO.

Even better, you can put that DVD ISO on a server on your network. Mount it on that server, and export the mount point via NFS to the rest of the network. Go to each machine in the network. Disable the source that uses the local optical drive. Add the NFS share from the server as an installation source on each box. Then, the machines on the network will pull packages from the NFS share.

Conclusion

There are at least a handful of ways to get installed what you need installed on your box. Depending on whether you are a home user with one computer or a Linux system administrator with 100 servers, or anything in between, you’re bound to use one or more of these methods. And these methods work on both OpenSUSE 10.3 and 11.0. Have a lot of fun…

May 23, 2008

Quick “what’s up?” alias for your .bashrc file

by @ 1:40 pm. Filed under bash, General Linux, SUSE Tips & Tricks

NOTE: Don’t use this, it has been updated. Go here for latest.

I was fooling around with an alias that would help someone know at a glance what machine they are on, who they are logged in as, their current path, the date, uptime, and some memory stats. This is something that I have found helpful when I have several remote servers open and logged into each one with several different accounts. It’s easy to know at a glance where I am doing what.

To implement this alias, pull open your ~/.bashrc file, and paste all of this at the end of it:

function memdisp {

MEM=`free -mot | head -n 2 | tail -n 1`
COUNT=1
for ITEM in $MEM
do
        if [ $COUNT -eq 2 ] ; then
                printf "  Total RAM:\t$ITEM Mb\n"
        fi

        if [ $COUNT -eq 3 ] ; then
                printf "  Used RAM:\t$ITEM Mb\n"

        fi

        if [ $COUNT -eq 4 ] ; then
                printf "  Free RAM:\t$ITEM Mb\n"
        fi

        COUNT=$[COUNT+1]
done

MEM=`free -mot | tail -n 2 | head -n 1`
COUNT=1
for ITEM in $MEM
do
        if [ $COUNT -eq 2 ] ; then
                printf "  Total SWAP:\t$ITEM Mb\n"

        fi

        if [ $COUNT -eq 3 ] ; then
                printf "  Used SWAP:\t$ITEM Mb\n"

        fi

        if [ $COUNT -eq 4 ] ; then
                printf "  Free SWAP:\t$ITEM Mb\n"

        fi

        COUNT=$[COUNT+1]
done

}

UPTIME=`uptime`
D_UP=${UPTIME:2}

alias sup="
printf '  my user:\t`whoami`\n'
printf '  my groups:\t`id`\n'
printf '  hostname:\t`hostname`\n'
printf '  domain:\t`dnsdomainname`\n'
printf '  date:\t\t`date`\n'
printf '  uptime:\t$D_UP\n'
printf '  kernel:\t`uname -a`\n'
memdisp
"

Then save the file, and run “source ~/.bashrc”. To use the alias, type ‘sup’ (short for “what’s up?”) and hit ENTER. You should see something like this:

[1457][scott@suse-linux:~]$ sup
  my user:      scott
  my groups:    uid=1000(scott) gid=100(users) groups=16(dialout),33(video),100(users)
  hostname:     suse-linux
  domain:       truenorth.local
  date:         Fri May 23 14:57:23 MDT 2008
  uptime:       2:57pm  up 5 days 18:35,  15 users,  load average: 0.17, 0.12, 0.13
  kernel:       Linux suse-linux 2.6.24-default #1 SMP Sat Jan 26 00:29:01 MST 2008 i686 i686 i386 GNU/Linux
  Total RAM:    1264 Mb
  Used RAM:     1234 Mb
  Free RAM:     30 Mb
  Total SWAP:   2055 Mb
  Used SWAP:    213 Mb
  Free SWAP:    1841 Mb
[1457][scott@suse-linux:~]$

This is great for when you come back to work from a long weekend, have 300 terminal windows open, logged into 32 servers with 43 different accounts.

If you wanted, you could also put this into the /etc/skel/.bashrc file so that all new users on your machine will automatically have this alias. Change to suit your taste.

If you do this, and an FBI satellite crashes into your new Porsche, it’s not my fault.

I am under no delusions of grandeur here. If you know of a better way to output the info, or more info that you’d like to output, or you modify/change it to make it better, please let us know. Suggestions, tips, tricks, comments, and even mild insults are welcome.

May 21, 2008

OpenSUSE 10.3 : Get started with these great resources

by @ 8:14 am. Filed under education, SUSE Tips & Tricks

Just taking the first few steps seems to be one thing that holds people back from doing something new. This is no different with Linux. This morning, I happened to be on the OpenSUSE.org 10.3 Installation Page, and found links to a couple of great “Getting Started” guides for OpenSUSE Linux 10.3. I realize that 11.0 is in it’s third Beta release and will be coming soon. But for a current, stable installation, many people are still using OpenSUSE 10.3.

Without further yammer, here are the links:

Step-by-step installation guide

Official openSUSE 10.3 Start-Up guide

I’d definitely recommend bookmarking those two resources. Great guides for getting started with OpenSUSE.

January 28, 2008

Want the new Linux 2.6.24 Kernel? Easy Upgrade Tutorial

by @ 7:11 am. Filed under General Linux, General SUSE, How-To, kernel, Linux tips, SUSE Tips & Tricks

INTRODUCTION

Now and then, you will likely need to familiarize yourself with a technically scientific process called “Fiddling With the Kernel.” There is quite a bit of documentation on this topic. I don’t want to go too far into the specifics of which options to set and how to tweak everything.

What I hope to do here is introduce you to a general overview of the steps involved with upgrading your kernel. I can hear it now, “You mean I can upgrade my kernel without knowing what CONFIG_INIT_ENV_ARG_LIMIT or CONFIG_USB_EHCI_ROOT_HUB_TT or CONFIG_SOUND_TRACEINIT means?” Why yes, yes, you can. I did this very process only yesterday, and I realized that I had done this process a number of times successfully. Thus, it seemed only fair to release it into the wild in hopes that someone else may benefit from it.

What on earth would possess someone to do something like upgrade a kernel? Well, let’s say you are using an RPM-based distro, such as OpenSUSE 10.x. You need the kernel source header files so that you can install the Nvidia driver for your new ultra-sick Nvidia card. You may need to compile the ndiswrapper kernel module. You may need to install VMware, which compiles a kernel module. Easy, right? Just install the kernel-source package that matches the kernel version you are running.

K, what if you have a newer kernel installed that the newest kernel-source package available? Or, what if you were anxiously awaiting some feature of the kernel that was just released, and you don’t want to wait for it to be available from a repository? There could be a host of reasons why you’d want to upgrade your kernel. This is a gentle introduction to one way of doing this.

Please be aware, though. You will usually not want to put a brand new kernel onto a production box, unless you have an exact reason in mind. Also, understand that you are doing this stuff at your own risk. Like I said, I did this yesterday, and have done it many times before. If you do it and your computer turns into radioactive hazardous waste (which it really shouldn’t do), don’t come crying to me.

All that disclaimer-ish junk out of the way, let’s get on to the cool stuff.

What will we be doing?

Step 1. – Download and unarchive the kernel source code
Step 2. – Prep and compile the kernel
Step 3. – Install the new kernel
Step 4. – Set up Grub
Step 5. – Reboot into the new kernel

GET THE KERNEL SOURCE

First things first. We’ll need the latest release of the kernel source code, available from none other than http://www.kernel.org/. On this page, you are looking for where it says, “The latest stable version of the Linux kernel is:”. Just to the right of the date on that line, there is a hyperlinked “F”. That is the Full source to the kernel. Right-click, copy the link.

Then, open a terminal and switch to root (with ‘su’). Change over to the /usr/src/ directory. Then, download the source using ‘wget’. When you’re done, unarchive it. This process should look something like this:

[1314][scott@linux:~]$ su
Password:
linux:/home/scott # cd /usr/src
linux:/usr/src # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.tar.bz2
--13:14:20--  http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.tar.bz2
           => `linux-2.6.24.tar.bz2'
Resolving www.kernel.org... 204.152.191.5, 204.152.191.37
Connecting to www.kernel.org|204.152.191.5|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 46,737,783 (45M) [application/x-bzip2]

100%[=============================================>] 46,737,783   578.56K/s    ETA 00:00

13:15:36 (604.56 KB/s) - `linux-2.6.24.tar.bz2' saved [46737783/46737783]

linux:/usr/src # tar -xvf linux-2.6.24.tar.bz2

Then you hang for awhile until the source decompresses.

PREP AND COMPILE THE KERNEL

Next, we need to make sure we have everything installed as necessary. Depending on the machine and what you already have installed, you may need to install one or more packages. Here are a few of the packages I have had to install to make things work properly:

gcc – this is the compiler – you won’t get far without this
nfs-kernel-server – on pre-OpenSUSE 10.3 boxes, use nfs-utils
oprofileabout this package
ncurses-devel

An easy way to see if they are installed or which need to be installed is with the rpm command. Install missing packages with yast. Recheck to make sure everything is there:

linux:/usr/src # rpm -qa gcc nfs-kernel-server oprofile ncurses-devel
gcc-4.2-24
linux:/usr/src # yast -i nfs-kernel-server oprofile ncurses-devel
linux:/usr/src # rpm -qa gcc nfs-kernel-server oprofile ncurses-devel
gcc-4.2-24
nfs-kernel-server-1.1.0-8
ncurses-devel-5.6-41
oprofile-0.9.3-25
linux:/usr/src # 

If one of the packages doesn’t show up, go ahead and use YAST to install it. Also, note that the one package is nfs-utils on OpenSUSE 10.2 and older, and nfs-kernel-server on OpenSUSE 10.3.

Next, we need to compile the kernel. Put away the defibrillation paddles. Contrary to popular belief, this step does not cause cardiac arrest (at least it didn’t in the lab rats we trained on kernel upgrades).

In your terminal, make sure you are in the directory with the kernel source code, something like /usr/src/linux-2.6.24/. Make sure you are working with a clean directory. Then, we are going to grab the configuration of the kernel that is currently running. This is as simple as:

linux:/usr/src # cd linux-2.6.24/
linux:/usr/src/linux-2.6.24 # make mrproper
linux:/usr/src/linux-2.6.24 # zcat /proc/config.gz > .config
linux:/usr/src/linux-2.6.24 #

Just about every time a new kernel comes out, new configuration options appear in it. If we were to just jump right in and start compiling the kernel now, it would stop when it reaches each new option and ask us what we want to do with it. Fortunately, there is a simple way around this. Unfortunately, the cost of simplicity is that you are accepting the default values for these options. But again, the object here is to keep it simple. If you’re feeling leet and hardcore, you can always go back and fiddle.

To get around this problem, we run make menuconfig just like if we were going to go in and hand-tweak the kernel. Instead of doing a thing, however, we tab over to EXIT and hit ENTER. We make sure to save the configuration.

We are ready to compile the kernel and all the modules, done by running this commandline:

linux:/usr/src/linux-2.6.24 # make ; make modules ; make modules_install

Because we have left everything with default settings, we will be compiling here for a long time. Actual time spent depends on your hardware specs.

INSTALL THE NEW KERNEL

When all the compiling finishes, you need to do two more things. You have to install the new kernel and configure grub to use it upon restart.

Next, we have to get our new kernel installed. We just copy a few files and create an initial ramdisk. We will copy the kernel image and System.map to /boot. We can then generate an initial ramdisk from that kernel and System.map file. Finally, I also like to back up .config to /boot as well, just so everything is in the same place. To accomplish all of this, these are the commands you will execute:

linux:/usr/src/linux-2.6.24 # cp arch/`uname -i`/boot/bzImage /boot/vmlinuz-2.6.24
linux:/usr/src/linux-2.6.24 # cp System.map /boot/System.map-2.6.24
linux:/usr/src/linux-2.6.24 # cp System.map /boot/System.map
linux:/usr/src/linux-2.6.24 # cp .config /boot/config-2.6.24
linux:/usr/src/linux-2.6.24 # mkinitrd -k vmlinuz-2.6.24 -i initrd-2.6.24

Kernel image:   /boot/vmlinuz-2.6.24
Initrd image:   /boot/initrd-2.6.24
Root device:    /dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 (/dev/sda2) (mounted on / as ext3)
Resume device:  /dev/sda1
Kernel Modules: processor thermal scsi_mod libata ahci pata_atiixp fan jbd mbcache ext3 edd sd_mod usbcore ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid
Features:       block usb resume.userspace resume.kernel
Bootsplash:     SuSE (800x600)
36561 blocks
linux:/usr/src/linux-2.6.24 #

Because I don’t really care to type all of that out every time, I have created a script that will do all of this for me:

#!/bin/sh

# EDIT THE KERNEL VERSION AS NECESSARY
KERNEL_VERSION=2.6.24

# REMOVE THESE FILES IF THEY ALREADY EXIST (I.E., IF WE ARE DOING THIS AGAIN
# FROM A PREVIOUS ATTEMPT)
# THE -f IS SO WE DON'T GET ALERTS IF THE FILES AREN'T THERE
rm -f /boot/bzImage-$KERNEL_VERSION
rm -f /boot/System.map-$KERNEL_VERSION
rm -f /boot/config-$KERNEL_VERSION

# COPY THE KERNEL OVER TO /BOOT AND BACK UP THE SYSTEM.MAP AND .CONFIG FILES
cp /usr/src/linux-"$KERNEL_VERSION"/arch/`uname -i`/boot/bzImage /boot/vmlinuz-$KERNEL_VERSION
cp /usr/src/linux-"$KERNEL_VERSION"/System.map /boot/System.map-$KERNEL_VERSION
cp /usr/src/linux-"$KERNEL_VERSION"/.config /boot/config-$KERNEL_VERSION

rm -f /boot/System.map
cp /usr/src/linux-"$KERNEL_VERSION"/System.map /boot/System.map

#MAKE THE INITIAL RAM DISK FOR THE NEW KERNEL
mkinitrd -k vmlinuz-$KERNEL_VERSION -i initrd-$KERNEL_VERSION
rm -f /boot/System.map

You should now have a kernel compiled very closely to the one your system is currently running, but with the newest kernel source. The compiled kernel image should now be in /boot, along with an initial ramdisk to go with it. All we have left is to set up grub to see the new kernel. Then, we can reboot into it.

SET UP GRUB

This is one of the easiest steps. We are going to open up a text file, copy and paste a few lines, change just a bit, and save the file back out. So go ahead and edit /boot/grub/menu.lst in your favorite text editor. You will see something like this:

# Modified by YaST2. Last modification on Sun Dec 30 21:00:56 MST 2007
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=0x314 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.13-0.3-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd /boot/initrd-2.6.22.13-0.3-default

Copy the section that begins with the line “####Don’t change this comment – YaST2 identifier: Original name: linux###” and ends at the line “initrd /boot/initrd-2.6.22.12-0.1-default”. Your version number may be different. We are just duplicating the original kernel entry. We are not going to edit that one directly, because we want to use it to get back into the system in case things go south.

You should now have something that looks like this (the green is what I pasted as a new entry):

# Modified by YaST2. Last modification on Sun Dec 30 21:00:56 MST 2007
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=0x314 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.13-0.3-default

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=0x314 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.13-0.3-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd /boot/initrd-2.6.22.13-0.3-default

Now, for the edits. Go to the ‘title’ line of that section you pasted. Change the title to reflect the new kernel, maybe something like this: “title openSUSE 10.3 – 2.6.24 [TEST]”. Then, we’re looking for the line that starts with “kernel”. Change the version on the end of “vmlinuz” to the correct version. In this case, it is 2.6.24. Then, change the line that starts with “initrd” the same way. These two paths are pointing to your new kernel image and your new initial ram disk image, respectively.

If you want to make sure that you have the paths correct, you can use file. If you have the correct files, this is what you will see:

linux:/usr/src/linux-2.6.24 # file /boot/vmlinuz-2.6.24
/boot/vmlinuz-2.6.24: Linux/x86 Kernel, Setup Version 0x207, bzImage, Version 2.6.24, RO-rootFS, root_dev 0x802, swap_dev 0x1, Normal VGA
linux:/usr/src/linux-2.6.24 # file /boot/initrd-2.6.24
/boot/initrd-2.6.24: gzip compressed data, from Unix, last modified: Sat Jan 26 19:44:58 2008, max compression
linux:/usr/src/linux-2.6.24 # 

If the files do not exist, you will see this:

linux:/usr/src/linux-2.6.24 # file /boot/vmlinuz-2.6.24
/boot/vmlinuz-2.6.24: cannot open `/boot/vmlinuz-2.6.24' (No such file or directory)
linux:/usr/src/linux-2.6.24 # file /boot/initrd-2.6.24
/boot/initrd-2.6.24: cannot open `/boot/initrd-2.6.24' (No such file or directory)
linux:/usr/src/linux-2.6.24 # 

At this point, you should have the right paths to these two files and that you have them in your menu.lst file correctly. It might look something like this (the green bits are what I have changed):

# Modified by YaST2. Last modification on Sun Dec 30 21:00:56 MST 2007
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.24 [TEST]
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.24 root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=0x314 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.24

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=0x314 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.13-0.3-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.13-0.3
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.13-0.3-default root=/dev/disk/by-id/scsi-SATA_WDC_WD1200BEVS-_WD-WXEX07392815-part2 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd /boot/initrd-2.6.22.13-0.3-default

With this step, we’ve opened the grub configuration file and made a copy of the entry running the current kernel. Then, we’ve changed it to give it a new title, and pointed it to the new kernel and initial ramdisk. Save the file and exit.

REBOOT INTO YOUR NEW KERNEL

All that we really have left now is to reboot into the new kernel. We still have the original installed and working. The grub configuration for the original is still intact. Because of this, if we have any problems whatsoever, we can just reboot and use that kernel instead. So, we can reboot with this command:

linux:/usr/src/linux-2.6.24 # shutdown -r now

Broadcast message from root (pts/2) (Sat Jan 26 20:32:20 2008):

The system is going down for reboot NOW!
linux:/usr/src/linux-2.6.24 # 

When the grub menu comes up, make sure you select the entry called “title openSUSE 10.3 – 2.6.24 [TEST]” (or whatever you called the new one). You should be able to boot just fine off this kernel (this process has always worked for me). If not, reboot and select the original one when the grub menu appears. This will get you back into your original kernel.

December 23, 2007

Make Broadcom Wifi Work With Ndiswrapper on openSUSE 10.3

by @ 10:10 pm. Filed under General SUSE, How-To, SUSE Tips & Tricks

So yeah, how you been? Me, good. Tryin’ to keep everything together… survivin’…. etc. K, let’s get to it.

Back in March, I bought myself a new laptop. The specs are on that link, but the hardware of interest to this article is the wifi card. It is a Broadcom BCM94311MCG. I’m not a wireless fan, so I didn’t worry about setting it up until recently, when I bought my wife a laptop for her birthday. Her card is the same as mine, but to use it, she had to boot into the Windows partition. As the truly informed can attest, this is unacceptable.

I set out to get the wireless working on my laptop so I could get Windows off hers. Go me.

The exact specs of the wireless card, as listed by 'lspci -v' are:

0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
Subsystem: Dell Unknown device 0007
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at ecffc000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 2
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Capabilities: [d0] Express Legacy Endpoint IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel

That’s the bad boy that we’re going to get set up with wireless in this very article on an openSUSE 10.3 laptop. Let’s have a moment of silence.

A basic outline of what we’ll cover: 1) First, determine the driver currently running the wireless card. We will then instruct the system never to load that driver ever again (and make a few threats just in case). 2) Second, we are then going to set up ndiswrapper to run the card. 3) Third and finally, we will set up the system so that when we reboot the machine, ndiswrapper is automatically loaded and we can hop on our wireless connection easily.

Out With the Bad

The kernel module that serves as the device driver for this wireless card is called ‘bcm43xx’. As root, remove it from memory, as in this example:

[2338][scott@laptop:~]$ su
Password:
laptop:/home/scott # rmmod bcm43xx

Now, we have to politely instruct the system to refrain from loading this module ever again. To do this, we are going to ‘blacklist’ the module. As root, edit /etc/modprobe.conf.local . Add this line to tell it to never load the bcm43xx module:

blacklist bcm43xx
In With the Good

Ndiswrapper is a way to use a Windows driver in Linux. Thusly, the first thing you need to do is grab said Windows driver from this link. Download it to somewhere that you will remember. When it is done, go there, and extract the file (can be done as regular user):

[2339][scott@laptop:~]$ tar -jxvf bcmwl5.tar.bz2
bcmwl5/
bcmwl5/bcmwl5.inf
bcmwl5/bcmwl5.sys
[2339][scott@laptop:~]$

Next, as root, let’s install ndiswrapper using YAST with this simple command:

[2340][scott@laptop:~]$ su
Password:
laptop:/home/scott # yast -i ndiswrapper 

Now we need to get ndiswrapper to run the wireless card. This is done as root as in this example:

[2341][scott@laptop:~]$ su
Password:
laptop:/home/scott # ndiswrapper -i /path/to/bcmwl5.inf

You can use ndiswrapper to make sure it worked like this:

[2342][scott@laptop:~]$ su
Password:
laptop:/home/scott # ndiswrapper -l
bcmwl5 : driver installed
        device (14E4:4311) present

If you see something like that, you are golden.

Next, we need to write a config file for ndiswrapper. This is done with the following command (as root):

[2342][scott@laptop:~]$ su
Password:
laptop:/home/scott # ndiswrapper -m

Remove all CAT-5 cables from your machine, and then let’s start up ndiswrapper (as root):

[2342][scott@laptop:~]$ su
Password:
laptop:/home/scott # modprobe ndiswrapper 

It’s just about set up. Now, we need to make sure it will work properly when we reboot. We also need to put in the wireless networking configuration for this adapter.

Make It Work Automatically on Reboot

Now obviously, when the machine reboots, we want to ensure that ndiswrapper is loaded and used to run this wifi card. To do this is absolute cake. Go into YAST, go into the Network Devices, and then into the Network Card. Select the Broadcom wifi card in the list of adapters. Click CONFIGURE. In the HARDWARE tab, there is a drop-down box called “Module Name”. Type ‘ndiswrapper‘ in there. Click NEXT to configure your wireless network settings for this adapter.

If you have set up the wireless access point, you should know all the configuration details that should be entered into this screen. If you don’t, you can ask your system administrator to help you figure it out. In any case, fill out this screen with all the appropriate information.

Click NEXT again, and then FINISH.

Take all CAT-5 cables out of your machine, and reboot. When it comes back up, use iwconfig and ifconfig to see if you have an IP address. Head to google and search for something. If you are able to do this, you are in great shape. As such, we are done here.

October 10, 2007

The Perfect Desktop – OpenSUSE 10.3 (GNOME)

by @ 6:43 am. Filed under General Linux, General SUSE, How-To, Linux tips, SUSE Tips & Tricks

Acquiring and retaining new users is how we are able to help grow the Linux user base. Contributing to this requires helpful and informative how-tos, much like those supplied by my good buddy Falko Timme. He has written many many great howtos and tutorials on good, better, best, and PERFECT ways to use Linux. One of his most recent posts includes “The Perfect Desktop – OpenSUSE 10.3 (GNOME).”

Excerpt:

“This tutorial shows how you can set up an OpenSUSE 10.3 desktop that is a full-fledged replacement for a Windows desktop, i.e. that has all the software that people need to do the things they do on their Windows desktops. The advantages are clear: you get a secure system without DRM restrictions that works even on old hardware, and the best thing is: all software comes free of charge.”

Take a look at this well-written post, as it is packed with excellent information. We’ll forgive him for recommending Gnome over KDE.

Read the entire post here.

OpenSUSE Linux Rants
Official OpenSUSE Linux Site

internal links:

categories:

SUSE Resources

search blog:

archives:

August 2018
S M T W T F S
« Feb    
 1234
567891011
12131415161718
19202122232425
262728293031  

77 queries. 2.966 seconds