Umbra's blog

Sed

2010-02-12T09:09:00.000-08:00

I will be posting sed related items in this space. Useful information can be found at:
http://www.gnu.org/software/sed/
http://www.unixguide.net/unix/sedoneliner.shtml

Remove hyphenation and join the lines together (rejoining the word). I don't think this works on two consecutive lines that end in hyphenation.

CODE
sed -e '/-$/{s///;N;s/\n//}'
EDOC

Radeon driver with Tyan Tiger MP motherboard Linux module incompatability

2009-11-13T08:58:00.000-08:00

Had a lot of trouble getting my ati radeon RV350 (9600) based card to work with Xorg under Debian lenny. It just wasn't setting the resolution correctly and everything on the screen "wiggled" just a bit, which would cause lots of headaches (literally). The problem is because DRI is failing to initialize, as per this entry in /var/log/Xorg.0.log:

----LOG----
(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
(II) RADEON(0): [agp] You may want to make sure the agpgart kernel module is loaded before the radeon kernel module.
----GOL----

The issue is in the load order of the related kernel modules for the motherboard chipset and the video card. I have a Tyan Tiger MP motherboard, which uses the AMD k7 chipset, but the solution is similar regardless of the motherboard chipset.

The relevant lines of lspci:

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
01:05.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600]

The solution was to blacklist the amd76x_edac module to by adding "blacklist amd76x_edac" to /etc/modprobe.d/blacklist .

Or you can use this snippit at your command prompt

#### CODE

echo 'blacklist amd76x_edac' | sudo tee -a /etc/modprobe.d/blacklist

#### EDOC

I am unclear what exactly this module does. You may loose some other functionality as a result of this blacklisting, so your mileage may vary, and i offer no guarantees.

A lot of related information can be found in the first few links of Google

Password safety net with ssss

2008-09-18T09:04:00.000-07:00

Short version: I lost all my passwords, but was fortunately able to recover them. None of this should have happened, because I am a stickler for this sort of thing.

However, it has taught me a valuable lesson about ensuring that passwords are safe. Here's how I have done it.

I am going to assume that you either have some knowledge of encryption, or are willing to take on faith that this will work. If you want to follow along with the recipe, you will need: *nix, openssl, ssss, a2ps.

First, create a file with your important passwords in it. This should be a plain text file since that is most accessible. The following scheme can even be used in a "in the event of my death" scenario, so it is useful to make it easy for others to access your file later. I will refer to this file as "passwords.txt".

Encrypt the file with a symmetric cipher and a password on the symmetric key. The password need not be memorable, at least not longer than until you finish the end of this task. It should be long enough that the password is not the weak link in your chain of protection; about 40 characters should do. It should also follow the usual guidelines for password security (see http://www.securityfocus.com/infocus/1537 ).

I did it this way, on a Linux command line:

CODE

dd if=/dev/random bs=40 count=1 | openssl enc -base64 | head -c 40 > random.txt

EDOC

Next the encryption. You can use gpg, pgp or some other encryption utility. Remember that you want symmetric encryption though. Here's mine:

CODE

openssl enc -aes-256-ecb -a -salt -pass file:random.txt -out password.enc

EDOC

You now have an encrypted password file. If you want to be able to store your passwords encrypted with a memorable password, just do this instead and enter a suitable password (try for at least 20 characters, and remember strong password rules):

CODE

openssl enc -aes-256-ecb -a -salt -out password.enc

EDOC

Back to the main story. Next you will create a scheme by which the password can be retrieved. This will entail splitting the password into (cryptographically sound) parts, or "shares". You need to decide how many shares are necessary to reconstruct the password, but you can generate as many as you like.

I decided to create 15 shares, of which any 8 are necessary to reconstruct the password. I kept 5 of them for myself, so I only need 3 collaborators to get my password file back. The other 10 I gave to family and friends. I also gave them a copy of the encrypted password file. While it would be possible for a group of 8 to collude to get my information, I trust them enough not to do so, and I also made sure that some of the individuals don't know each other.

Unfortunately, the command requries you to enter the password to be split manually. I recommend using the clipboard, since it doesn't even prompt you a second time to verify you input it correctly, and also doesn't output to the screen. You should change the numbers to suit your needs, but leave the 1024 as is.

CODE

ssss-split -t 8 -n 15 -s 1024 > shares.txt

EDOC

Each line of shares.txt is a share; distribute them as you see fit.

While this is not the point of this post, it is a good idea to test that everything works by reversing the process before you delete anything, as follows:

CODE

ssss-combine -t 8

EDOC

That should have returned the original password.

CODE

openssl enc -d -aes-256-ecb -a -in password.enc -out password.test

EDOC

password.test should be identical to password.txt.

I put my password.enc and shares.txt on paper thusly:

CODE

a2ps --columns=1 -B password.enc > password.enc.ps
a2ps --columns=1 -B shares.txt > shares.ps

EDOC

I printed these off, and made 11 copies of password.enc.ps. I gave one to each individual getting a share. I also printed the shares, cut out each share with scissors, and passed them out.

Last but not least, delete things (be sure you are finished first!):

CODE

shred -u -z passwords.txt passwords.enc passwords.enc.ps shares.txt shares.ps random.txt password.test

EDOC

You must distribute the shares. Keeping them all in one place is the same as having your password written down!

Debian server configuration : sudo

2007-07-03T14:29:00.000-07:00

Sudo is a (IMNSHO) better way to handle root user access than su. It does allow you to run commands as users other than root, but that will not be covered in detail here.

Sudo's config file resides at /etc/sudoers. Sudo is very particular about it's config file: anything that isn't exactly as it should be causes sudo to fail to run. This is a security feature, do not complain. Therefore, you should get in the habit of frequently running "sudo -v" to validate sudoers as you edit. Specifically, do not close your editor until you have validated sudoers.

sudo will also fail to run if write permission is granted on the config file, so editing it directly can cause problems, especially since the configuration settings suggested below disable su.

Instead, you should set your shells EDITOR and/or VISUAL variables to an editor of you liking (the default is vi). You may then invoke "sudoedit /etc/sudoers" to edit the file. Remember to run "sudo -v" before closing the editor!

#----Begin sudoers edits

# Create an alias which contains the
# privelged access commands,
# namely su and sudo.

Cmnd_Alias SU = /bin/su, /usr/bin/sudo

# It may be possible for a user to
# circumvent sudo's logging facilities
# by running certain shells. Therefore,
# we prohibit running shells via sudo.

Cmnd_Alias SHELLS = /bin/csh, /bin/sh, \
/usr/bin/es, /bin/ksh, /usr/bin/ksh, \
/usr/bin/rc, /usr/bin/tcsh, /bin/tcsh, \
/usr/bin/esh, /bin/bash, /bin/rbash, \
/bin/zsh, /usr/bin/zsh

# The following line should be
# included by default.
root ALL=(ALL) ALL

# Replace "admin" with username
# of the administrator account
# You can also use a comma
# seperated list, or a User_Alias
# similar to Cmnd_Alias to
# create a list to be used.
# A third option is to use %group,
# where "group" is a usergroup defined
# in /etc/groups.
#
# This grants access to "admin" to
# run any command on any host,
# but does not allow admin to
# run as any other user.

admin ALL=ALL

# The order of this entry is important;
# it should generally be the last entry!
# This disables any user from running
# su, sudo, or any shell via sudo.

ALL ALL=!SU, !SHELLS

#----End sudoers edits

sudo is included in the SU alias to safegaurd ourselves: If user A can run commands as user B, and user B can run commands as root, then user A can run commands as root via sudo. Including sudo in the list prevents us from mistakenly causing this.

It is important to keep the shell list up to date with shells you install: See /etc/shells to view all your installed shells.

If you would like to add more entries, the format of access entries is:
userlist hostlist=(userlist) commandlist

A list is a comma seperated list of the specified type. Generally, hostlist should be ALL.

It is usually not necessary to specify the (userlist) entry. It is used to allow that entry to be run as anyone (i.e. user) in (userlist). Not including it means the user the command can be run under can not be changed.

If you would like "admin" to be able to run commands as any user, add him to the "root" line instead of specifying his own entry:
root, admin ALL=(ALL) ALL

Note that these settings do not disable su entirely. If someone learns the password to a login account (such as root), they can still change to that user via su. Removing this functionality is beyound the scope of sudo. You may remove su from your system, but this may cause some systems to break (you have been warned). You could also disable certain logins (such as root), by setting their password (2nd field) in /etc/shadow to *, but again this may break things (and you have been warned again).

More information can be found at:
man sudo
man sudoers
http://www.linuxhelp.net/guides/sudo/
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch09_:_Linux_Users_and_Sudo

Debian server configuration : sshd

2007-06-30T14:00:00.000-07:00

Your sshd configuration files is located at /etc/ssh/sshd_config.

The following discussion applies to the Debian openssh-server package, specifically lenny as of time of posting. If you are using some other system/version, some settings you likely should change will not be covered here, because the Debian defaults are to my liking. You have be WARNED!

Some of the default settings that openssh-server comes with make me extremely nervous. The security is too lax. Here are some changes i like to make to tighten things up to my personal level of paranoia. YMMV.

ListenAddress
Set this to network interface you wish sshd to accept connections on. It is good practice to set this even if you have only one interface, so sshd will fail if your network configuration changes mysteriously, and (possibly) to help prevent some spoofing.
You may specify more than one interface by using multiple ListenAdress entries. For instance, you may wish to include a ListenAddress 127.0.0.1 in addition to any external interfaces, though i don't recommend this.

Protocol 2
Definetely should be set to 2, unless you have a very good reason to do otherwise.

Hostkey
You should comment out any entries for protocol 1, even if you have specified Protocol 2 explicity above. Could save you pain in the future.

ServerKeyBits
If you don't mind more cpu overhead, and you feel paranoid, add some more bits until satisfied.

KeyRegenerationInterval
If you are truly paranoid and don't mind cpu overhead, set this to a smaller value (it is in seconds, so 3600 = 1 hour).

PermitRootLogin no
Highly recommend this set to no. Forces users to login as a regular user, and then use sudo to do any actions as root. As a side benefit, you will be able to track such things better in your logs.

RSAAuthentication no
Should be no, especially if using Protocol 2.

IgnoreUserKnownHosts yes
I'm paranoid, so i turn this off (i.e. yes). It probably is safe to leave it no.

PasswordAuthentication no
Again, paranoia. Tunneled passwords are generally safe. That is, they are as safe as the passwords themselves (which can mean, "not very"). But PubkeyAuthentication is better. Turning all forms of authentication except Pubkey off means Pubkey is the only way, which is nice and safe. However, disabling this will likely mean the system administrator (i.e. you) is involved in giving each user ssh access, each and every time. You decide.

ChallengeResponseAuthentication no
Once again, i only really trust PubkeyAuthentication, so this gets turned off (i.e. no). In reality, s/key is generally safe to use.

More information can be found at:
http://www.faqs.org/docs/securing/chap15sec122.html
http://www.gentoo.org/proj/en/infrastructure/config-ssh.xml?style=printable

Debian server configuration : tcpd / libwrap

2007-06-30T13:50:00.000-07:00

Editing /etc/hosts.allow and /etc/hosts.deny to tighten up security. See man hosts_access for information.

I subscribe to the "that which is not explicitly allowed is denied" philosophy of security. Therefore, my /etc/hosts.deny has only one line:
ALL:ALL

That is, deny everything to everybody (unless it is specifically granted in /etc/hosts.allow).

Doing this will require you to name all services which you wish to grant access to in /etc/hosts.allow. An example you will likely find useful is:
sshd: 192.168.

This means allow ssh access to anyone on the internal (192.168.x.x IP's do not route on the Internet) network. You will likely wish to suplement this with firewall rules that verify that packets entering from the Internet are not spoofed to apear to come from your internal network before allowing them into your server.

Debian server configuration : apt

2007-06-30T13:38:00.000-07:00

I like to be able to pull in packages from unstable occasionally, though i avoid it as much as possible to keep my system from becoming... well unstable. To be able to do this, you must edit your /etc/apt/preferences similar to the following:

#BEGIN /etc/apt/preferences

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 900

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Package: *
Pin: release o=Debian
Pin-Priority: -1

#END /etc/apt/prefrences

Similarly, you can setup pulling testing packages into a stable system by replacing all instances of "testing" with "stable", and then all instances of "unstable" with "testing".

You will need to setup an apt source (in /etc/apt/sources) for the target release (i.e. "unstable" in the example above) and then perform an "apt-get update".

Afterwards, you can install packages from unstable with:
apt-get -t unstable install some-pakage

If you wish to install packages from your default release (i.e. testing in the example above), just use apt-get normally, without the -t switch.

This was pulled in large part from the following pages, which will give you a more complete explanation:
http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-pin
http://jaqque.sbih.org/kplug/apt-pinning.html
http://wiki.serios.net/wiki/Apt-Pinning_on_Debian
http://wiki.debian.org/AptPinning

Debian server configuration : apt

2007-06-30T13:29:00.000-07:00

Added 00queuemode into /etc/apt/apt.conf.d with the following contents:
APT::Acquire::Queue-Mode "host";

This speeds up "apt-get update && apt-get dist-upgrade" if you use more than one apt source, as i do. It tells apt to download in parrallel, one connection per source in /etc/apt/sources

Debian lenny server installation

2007-06-30T12:56:00.000-07:00

Recently began a server installation, and have decided to document it here for others to learn from my mistakes.

I have been running Debian for about 7 years now, and linux for about 9. I have administered a few servers before now, this effort is to create one that will be fairly self-sufficient. That is, i won't need to spend a lot of time maintaining it. Yes, i know i am lying to myself.

The hardware is a dual Athlon 3200 system on a Tyan Tiger MP motherboard with 1GB of RAM.

During installation, i partitioned thusly:

hda1 : 1.5 GB : swap
hda2 : 100MB : ext3 : /boot
hda3 : The rest : physical partition of LVM volume
LVM : xfs : /

I chose to put /boot on it's own drive so i could format it as ext3. I've had problems with the Debian installer loading grub onto xfs partitions.
Even though i am only using a single drive, i chose to use LVM to make future expansion easier. When i add a new drive, all i need to do is add it to LVM, and / gets bigger.

I did not seperate the drive into more partitions because i have found this typically leads to wasted drive space. Instead, my plan is to create files with filesystems in them, then mount them via loopback on certain points of the directory, such as /var and /home.
This has the following benefits:

Enlarge the files as needed
Add compression and encryption at a later date
Bulk backups of these brances of the directory tree are easy

It has one disadvantage i can think of:

Adds an extra layer of "dereferencing" on all access to these "partitions", making it a bit slower

After installation, i remove /tmp and replace it with a link to /dev/shm.

CODE (as root)
cd / && rm -r tmp && ln -s /dev/shm tmp
EDOC

I do the same for /var/tmp and /var/lock. I also remove /var/run and replace it with a link to /lib/init/rw. These choices were made to preserve the directories permissions.

I highly recommend the above on all systems, as it speeds up /tmp (and the rest) considerably, with no loss of functionality. You may wish to make you swap drive larger if /tmp is used a lot on your machine.

I experienced problems with resuming from sleep/hibernate with this configuration. However, on a server, this should never occur, and therefor this should be simple enough.

I installed only the base system, and then installed all the packages i want manually via apt.

First however, i removed the following packages:

portmap
nfs-common

Neither of these should be in the base install IMNSHO.

I added the following, which i recommend for server installations:

git
openssh-server
sudo
deborphan
localepurge
gnupg
ntpdate

Additionally, i added the following, since my server will be sitting idle a lot, and i want to save as much power (and lower it's thermal output) as much as possible:

acpid
noflushd
powersaved
hal-device-manager
powertop
cpufrequtils

In addition to using git for all the projects i work on, i also use it to track /etc changes. My method is to add files immediately before first editing them. Some people i know just track the whole directory. I find the latter approach inefficient, as it tracks all of the Debian updates as well as my own, but it is a lot simpler.