yum rollback feature / rpm rollback feature

Doing some upgrades this week on a production system and don't want anything to break...So, I looked into this.

One of the least-known secrets about rpm is that it can rollback (undo) package changes. It can take a fair bit of storage space to track the information necessary for rollback, but since storage is cheap, it’s worthwhile enabling this feature on most systems.
Here are cut-to-the-chase directions on using this feature:

1. To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.
   
2. To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros.
   
3. Install, erase, and update packages to your heart’s content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.
   

If/when you want to rollback to a previous state, perform an rpm update with the –rollback option followed by a date/time specification. Some examples: rpm -Uhv –rollback ‘9:00 am’, rpm -Uhv –rollback ‘4 hours ago’, rpm -Uhv –rollback ‘december 25′.

php5 / suhosin extension (not patch) on CentOS or RHEL

Red Hat / CentOS Linux Install Suhosin PHP 5 Protection Security Patch

Q. Wordpress and many other open source application developers asks users to protect PHP apps using Suhosin patch to get protection from the full exploit. Suhosin is an advanced protection system for PHP installations. It was designed to protect your servers from various attacks. How do I install Suhosin under RHEL / CentOS / Fedora Linux?

A. Suhosin was designed to protect your servers against a number of well known problems in PHP applications and on the other hand against potential unknown vulnerabilities within these applications or the PHP core itself including wordpress and many other open source php based apps.

Install Suhosin as extension

Download latest version of Suhosin, enter:
# cd /opt
# wget http://download.suhosin.org/suhosin-0.9.27.tgz
Make sure you have php-devel installed:
# yum install php-devel

Compile Suhosin under PHP 5 and RHEL / CentOS Linux

Type the following commands:
# cd suhosin-0.9.27
# phpize
#./configure
# make
# make install

Configure Suhosin

Type the following command to create Suhosin configuration file:
# echo 'extension=suhosin.so' > /etc/php.d/suhosin.ini

Restart web server

Type the following command to restart httpd:
# service httpd restart
If you are using lighttpd, enter:
# service lighttpd restart

Verify Suhosin installation

Type the following command:
$ php -v
Sample output:

PHP 5.1.6 (cli) (built: Jun 12 2008 05:02:36)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with XCache v1.2.2, Copyright (c) 2005-2007, by mOo
    with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

You can find more information by running phpinfo():

phpinfo();
?>

Sample output:

Fig.01: Suhosin information and settings displayed by phpinfo()

setup bridging br0 eth0 on Centos or RHEL for KVM virtual machines

There were several places online I could've visited to help me get bridging going on my system...They all seemed to be written for a home user though.

I recently setup a new CentOS 5.4 workstation on a machine here at work, and have been planning on moving everything over to that from my Mac Management station. Currently using a Macbook Pro as a management station but I'd like to free it up to do other things...

Also I wanted to do some KVM virtualizing because thats how RedHat does it, and thats our vendor...so...

For starters, I needed to let any VM's I created have bridged access to the network... This was probably the most difficult part, because it was just a mixed-bag when it came to how other people had done it. Here's how I did it, and it works for me.

The interface is an Intel gigabit card (wasn't supported until 5.3 out of the box!), so 1 physical interface formerly known as eth0.

`yum install bridge-utils` will install the proper utilities to enable bridging, and should also enable the kernel module on most distros.

I guess the tricky thing is, when you use bridging, you're actually kind of saying "ok bye eth0, we're going to replace you with br0 and then let br0 hand out access to any other interfaces" - This is hard for some people to grasp...

So goto /etc/sysconfig/network-scripts and `cp ifcfg-eth0 ifcfg-br0`

Then edit ifcfg-br0 to contain the following information:
DEVICE=br0
BOOTPROTO=static
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=x.x.x.x
GATEWAY= x.x.x.1
TYPE=Bridge
USERCTL=no
IPV6INIT=no
PEERDNS=yes



Then edit ifcfg-eth0, it should just have
DEVICE=eth0
ONBOOT=yes
BRIDGE=br0

-
You should then reboot. your main interface will have become br0, and eth0 will just be sitting there...waiting...for something.

Anyway,
You can use brctl show to show the current bridges on your system, and it gets more complicated from there on out.

You can then assign eth0 to virtual machines in the Virt Manager and the vm will use that as its bridge access. ;)

pidgin, otr, and random number generation

on a new centos plus workstation (5.4) i was trying to IM with pidgin and otr with my friends. we use OTR for private communication.

the key generation was failing, hanging actually, strace showed some problem with timeouts and /dev/urandom.

On the advice of someone who ran into the same problem, I used rngd to feed /dev/urandom into /dev/random

rngd -o /dev/urandom -r /dev/random

This worked and key generation completed successfully. Joy.

Pam Update, security pam_limits and 64 bit libs

ok, so, you have an x64 server and you updated pam, and you want to use pam_limits - cool story. until you try to login...and you're like, why isn't it working? because you added the line:

session required /lib/security/pam_limits.so

to /etc/pam.d/login

but you CAN login remotely and you check your log files and see 'Module unknown' when someone tries to login locally. This is because you're a 64bit server using a 32bit library...from /lib...so change that line to

session required /lib64/security/pam_limits.so

Then local logins work. =)

Updated on SSH Key authentication.

Public key authentication is great, as most of us have known for years, but I'm still in the middle of converting everyone to it who use the systems where I work.  Its actually a pretty big task since so many people do have to connect into our servers in order to get information...and if those accounts cannot connect then...well, stuff starts breaking.

We've done really well and our systems are really stable, of course they're still running HP Unix, but the new systems that are on their way into production are RedHat Linux (RHEL 5), so we have our work cut out for us. No problem -- They seem to be quite resilient and stable.  I wish we could get some Oracle on BSD. Grr.

Anyway, a lot of interesting changes going on in the workplace right now, so, I'll leave those for another time. Just wanted to give a quick update to all the readers out there... I'm still alive. Thanks for your emails.

SSH and SSH Key Pair Authentication instead of Passwords

Well, some of the users where I work were wanting to know what makes key authentication better than password authentication... Its a difficult thing to explain when people are unaware of the advantages of key auth, and the risks of password authentication. I suppose I try to explain it away with "this will actually make it simpler in the case of a compromise" ... So I may post more about this later, but a general reasoning behind this is described well by some PuTTY documentation.

Public key authentication - an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.
In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.
Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.
So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.
There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.
This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY's authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.
There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.

sudo, su, and you. oh, and root. and some tips...

sudo(8) executes commands as a different user on Unix systems, as allowed by the sudoers configuration file. Commands run via sudo are logged via syslog, providing an audit trail. While sudo may not work on your friends, I consider it essential to system administration.

• sudo homepage.
   
• Managing /etc/sudoers with CFEngine.

Alternatives

Consider also sudosh, or special logbash versions of the shell that log all commands. Never use the unsafe and unlogged sudo -s, sudo -i, and su commands. Between sudo and proper configuration management, logging in as root should be a very rare occasion.

List Commands

To see what commands can be run on a system, issue sudo -l. Depending on the sudoers configuration, this may prompt for the user’s password.

$ sudo -l
User admin may run the following commands on this host:
(ALL) NOPASSWD: ALL

If root is allowed to run sudo, one can inspect what commands another user may run:

$ sudo sudo -u someotheruser sudo -l
User someotheruser may run the following commands on this host:
(ALL) NOPASSWD: /usr/sbin/cleanup-logs

If administrators are allowed to sudo to any other user, this can be done directly via:

$ sudo -u someotheruser sudo -l
User someotheruser may run the following commands on this host:
(ALL) NOPASSWD: /usr/sbin/cleanup-logs

Configuration

The sudoers configuration file uses Extended Backus-Naur Form (EBNF), which is flexible but complex. For an overview, see the sudoers(5) documentation.

• Always use visudo(8).
The visudo command should be used to edit the sudoers data. Otherwise, errors or permissions problems may crop up randomly. If building a complex sudoers file using configuration management software, sanity check the resulting data with visudo -f tempsudoers -c before moving it into production use.
• Last entry wins
The last matching rule in sudoers wins; that is, if a NOPASSWD entry is followed by an entry that requires the implicit PASSWD, the user will be prompted to enter their password.
ALL ALL=(ALL) NOPASSWD: ALL ALL ALL=(ALL) ALL
$ sudo -l User admin may run the following commands on this host: (ALL) NOPASSWD: ALL (ALL) ALL $ sudo -k; sudo /bin/ls Password:
To avoid this problem, place NOPASSWD entries after any entries that require a password. The following requires passwords for all commands excepting xinetd service changes on a RedHat Linux system:
%wheel ALL=(ALL) ALL %wheel ALL=NOPASSWD: /sbin/service xinetd *

Disallow Shell Access

Use the following configuration to avoid needless use of unsafe and unlogged shells. Encourage users to avoid launching a root shell, and reserve a special logbash shell that logs all commands for the rare occasions a root shell is needed.

# specify full list of shells and login commands here
Cmnd_Alias SHELLS= /bin/sh, /bin/ksh, /bin/bash, /bin/zsh, \
/bin/csh, /bin/tcsh, \
/usr/bin/login, /usr/bin/su

%wheel ALL=(ALL) ALL, !SHELLS

If the configuration is correct, a user attempting to gain shell access will be properly rejected:

$ sudo -s
Sorry, user jdoe is not allowed to execute '/bin/zsh' as root on …
$ sudo -i
Sorry, user jdoe is not allowed to execute '/bin/sh' as root on …
$ sudo su
Sorry, user jdoe is not allowed to execute '/usr/bin/su' as root on …

OpenSSH and SSH.COM Key generation - Some Concerns...

Where I work some people use a very old commercial SSH Client - Its from circa 2002 and its really not that great.  So we're switching to key based auth -- This brings some problems about.  Some of my users will be using this antiquated client which generates some ugly keys. I'd prefer everything be openssh based. So, I found some information about this on someones blog, and I decided I would share it here on my blog, and leave it here for my reference as well as yours! Happy converting.
--

Connecting two server running different type of SSH can be nightmare if you does not know how to convert the key. In this tutorial, I will try to explain on how to convert the public key from OpenSSH to SSH2 and SSH2 to OpenSSH. To convert the key, it must be done in OpenSSH server.
Convert OpenSSH key to SSH2 key

• Run the OpenSSH version of ssh-keygen on your OpenSSH public key to convert it into the format needed by SSH2 on the remote machine. This must be done on the system running OpenSSH.
  #ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh/id_dsa_ssh2.pub

Convert SSH2 key to OpenSSH key

• Run the OpenSSH version of ssh-keygen on your ssh2 public key to convert it into the format needed by OpenSSH. This needs to be done on the system running OpenSSH.
  #ssh-keygen -i -f ~/.ssh/id_dsa_1024_a.pub > ~/.ssh/id_dsa_1024_a_openssh.pub

Steps involved to produce and convert the keys.
OpenSSH
To generate an OpenSSH sshv2 key
$ ssh-keygen -t dsa -f newkey
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in newkey.
Your public key has been saved in newkey.pub.
The key fingerprint is:
c6:db:3a:ff:4c:79:a7:d8:cb:be:82:e8:9d:db:8c:e9 brad@eta
To export to ssh.com
$ ssh-keygen -e -f newkey.pub
—- BEGIN SSH2 PUBLIC KEY —-
Comment: “1024-bit DSA, converted from OpenSSH by brad@eta”
AAAAB3NzaC1kc3MAAACBAJ7QKkrLoOE9TNPVmKVedk1GAr/S+Cruq3/GtjRnxvJqbBbfne
lWYUC+vbHc5a+7bgRsQfCgoCeGKH5wGD4CDWQMhy2XYomnGf1gUC86Hq77/Noqa02N441E
FSTIEoNlU2aYi8zwVQKlgP6e22mG9sK7zSaGX639ctaigHuST8qPAAAAFQC2az8dfxHkkD
ZAEw+RcvRn3cpXFQAAAIEAgYpPs6d+Kyw37ZaBarlMEaZoEfrxhUZ44SN+KoqBZYpSVwyH
J+/RB0zVUizXCmZ5RhYSsYZ57Iixx1bBmBxogaEh5d7xxUpg/9Xctf94Jsf7vxccjZ4XYA
RrVikq/0L9fuKOmo4ET9iAf+GL7w2u5gzxxZr+xX5jw/A7907lOCwAAACAMoHHk0o1XkG+
yeaPtuwbrHshGqTjpOUkJ/AYuQ8OBuVAOdqse1di9JpeHko26G0zoH3N+nDHMGdYYTNHzR
NYRd2q20ztcAP52crZo1rtpNdvs6c+RTEIgoP3oYh1e1+rg70tWKIW3R/NYB39CESHoyqs
AJ7vzOPm0iUOd36YECY=
—- END SSH2 PUBLIC KEY —-
SSH
To generate a key:
$ ssh-keygen
Generating 2048-bit dsa key pair
1 oOo.oO
Key generated.
2048-bit dsa, marshalb@obelix.cqu.edu.au, Tue Jul 15 2003 13:53:34 +1000
Passphrase :
Again      :
Private key saved to /usr/users/staff/m/marshalb/.ssh2/id_dsa_2048_b
Public key saved to /usr/users/staff/m/marshalb/.ssh2/id_dsa_2048_b.pub
To convert from ssh.com to OpenSSH (using OpenSSH ssh-keygen):
$ ssh-keygen -i -f id_dsa_2048_b.pub
ssh-dss AAAAB3NzaC1kc3MAAAEBAKueha6mfr5OUcscc88lmQUBBgYSZ08htHFaYzke2N
5WG6ql1NgwQsyY2mMRxvvGckBeInx2GvRlz1+izDs5p4UGhkMzG8qOoT2y2vLwTFQyxi4I
XET1e0E8VYC0dcLfs5Zg6RxEY7GA5FiydS6dceuPnLJgCYDfyb9Qbk4rVEvREODo8dV/KR
lZxecEgaeKOO7ZnEzaIVPRCVb6U6EaRtZvxKfGnNFI957AfZ+Hqevz1IeQNDCp00EmaNli
8Ow4rjOPlH7o818r35Ea8mMoV0hkirNQ25zf/Z1LvCS3649537YDi/SVmMMpGCvT93w/TR
vk5RKlwVVy+TH52C8/MKEAAAAVAOuDCV61LvfKz0bd8hYEJ/gGof9XAAABAQCFRhlpWtVO
hTxcWcrnZp9EbbVRZO16St5TPjL86khb7b/VjScOAgt0tslHwtEEQzImv1xRkk6ZQ1o9pv
Azb1fMZrZMGIy9zUXvL0v6LNXxCxN9YIjx14OXYfH8EIQDZJGRJoxHvEvUVjv3lHnTuxbd
Krcbagvakxvgjq1wVyEueilO+g+WhJm+Q+XIYRl0TK9qtsAVFmzxBxT5USZFJ+1kbG7ipp
fFSGWRd3KPUCVQ8iGO3IMjtIlfcuGOArbKB06kMlxsdjNjhcEIHtR0jpaEeB2X+HrVScQE
oXG4S8YkiIExlIvjhrVr571BTOuO9H5VHt4CtKUxeXxKZWslulYwAAABAHm3zlMsXxPL/H
Oq29qf7Lk90b7El+j19E2UkyssfSu6+/k4bFf6ax2n3yEn31S5bUdNvgqmlEjdERc4SkU6
5b5LW2ZI1v7kRoegG+bD2Q21N9Rv/lwS7CTprenKiMMRJ8TU7FMIVT3zEZkV+etC7cbaN+
09GoiFTt+h7IDmo7onlo64oSMrcc+xt++ZUzENTVBgDoS92jlpnELkyJqZgb1/fdEPT6wR
j132yBxWLqDGmbp9msmY1us+XNDY8isF80u9yTTXGTskOtCSaeavDDtPOKN5ZR20sHpIBg
t6zd6mm/zKD6OZo14BLSJr7ldwSRzNNYMtkLnNyFSYxAIrm9Y=
You can then use the output in authorized_keys file on an openssh box.
OpenSSH v2 -> SSH v2
On the OpenSSH box, create a DSA key via the following:
$ ssh-keygen -t dsa
Export the key into ssh.com v2 format:
$ ssh-keygen -e -f ~/.ssh/id_dsa.pub > newPubKey
Copy the converted ssh key to the ssh.com server
$ scp newPubKey server:.ssh2/id_dsa.pub
On the server, tell the ssh.com server that the public key is allowed:
echo “Key id_dsa.pub” >> ~/.ssh2/authorization
SSH v2 -> OpenSSH v2
On the ssh.com box, generate a DSA key:
$ ssh-keygen
Copy the generated key to the openssh box:
$ scp ~/.ssh2/id_dsa_1024_a.pub server:.ssh
Convert the public key to openssh format and append to authorized_keys:
$ ssh-keygen -i -f id_dsa_1024_a.pub >> ~/.ssh/authorized_keys
On the ssh.com box setup the private key:
$ echo “IdKey id_dsa_1024_a” >> ~/.ssh2/identification
SSH v2 -> SSH v2
On the ssh.com client, generate a DSA key:
$ ssh-keygen
Copy the generated key to the server:
$ scp ~/.ssh2/id_dsa_1024_a.pub server:.ssh2
On the server, tell the ssh.com server that the public key is allowed:
$ echo “Key id_dsa._1024_a.pub” >> ~/.ssh2/authorization
On the ssh.com client setup the private key:
$ echo “IdKey id_dsa_1024_a” >> ~/.ssh2/identification
OpenSSH v2 -> OpenSSH v2
On the OpenSSH box, create a DSA key via the following:
$ ssh-keygen -t dsa
Copy the ssh key to the server
$ scp ~/.ssh/id_dsa.pub server:.ssh/id_dsa.pub
Add the key to the authorized_keys file on the server
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Oracle on Linux needs access to /proc? Only for Enterprise Manager?

So, on some of our systems oracle runs as the oracle user, and the /proc filesystem is off limits for standard user accounts. This hasn't affected much...however I came across the error:
Error retrieving information from EMD. Exception: oracle.sysman.emSDK.emd.comm.MetricGetException: Could not open /proc/partitions

today...Hrm. Wonder what thats hurting...Probably nothing as everything seems to be running properly.

In addition...uname must be unrestricted in order for Oracle Wallet Manager (owm) to function. Probably lots of other java stuff too.