Showing posts with label red hat. Show all posts
Showing posts with label red hat. Show all posts

Tuesday, January 22, 2013

RHEL 6 kickstart maps first hard drive to /dev/sdc

I was installing RHEL 6 on a Dell PowerEdge R610, and for some strange reason the first drive was mounted as /dev/sdc instead of /dev/sda. I saw someone else had the same issue on CentOS 6:

https://www.centos.org/modules/newbb/viewtopic.php?topic_id=36632

The solution: disable the iDRAC virtual media. I had to press Ctrl-E to get into the DRAC menu when it prompted me during the boot process, then I had to arrow down to Virtual Media Configuration and change the Virtual media setting from attached to detached.

Or from the iDRAC web interface: System --> Console/Media --> Configuration --> Virtual media --> Status --> change to Detach --> Apply

Now the first drive is mapped as /dev/sda again.

Wednesday, January 9, 2013

Dell DSET: Failed to gather Chassis/Storage data.

Trying to run Dell's DSET tool on Linux (RHEL), if it fails with the following error after entering the root password:

Failed to gather Chassis/Storage data. Check the IP Address, credentials and namespace.

Make sure you entered the root password correctly. Reset the root password if you're not 100% sure.

Wednesday, October 24, 2012

sudo -s on RHEL 6 doesn't preserve HOME

Solution:

If you're the only one using this machine, the easiest fix is to run this command as root:
visudo

and then add this line to the sudoers file:
Defaults env_keep=HOME

If this is a shared computer and you aren't at liberty to change the sudoers file, you can add this code to .bashrc in your home directory. be sure to log out and back in for it to take effect:

# hack to preserve home when using sudo -s on rhel 6
if [[ `cat /etc/*release | grep "release 6"` ]]; then
    sudo() {
        if [[ $@ == "-s" ]]; then
            sudo bash -c "HOME=$HOME; exec bash"
        else
            command sudo "$@";
        fi;
    }
fi;


Details:

In linux, if I want to become root but keep my user's environment (home, aliases, etc), I normally use sudo -s:
[user@computer ~]$ sudo -s
[root@computer ~]# echo $HOME
/home/user


and if I want to become root and use root's environment, I'll use sudo -i:
[user@computer ~]$ sudo -i
[root@computer ~]# echo $HOME
/root


The above works on Ubuntu, and all versions of RHEL up to 5 (the same probably goes for CentOS). however, I recently noticed that RHEL 6 , my home variable isn't preserved when using sudo -s:
[user@computer ~]$ sudo -s
[root@computer user]# echo $HOME
/root


The most frustrating thing is that because of this, it seems like my .bashrc wasn't being called, and so I didn't have access to my aliases any more.

It seems like the cause of this is that the default in RHEL 6 is not to preserve the home variable. you can see this running this command as root:
sudo -V

If you look under the list of "Environment variables to preserve," you'll notice that in RHEL 5 HOME is listed, but in RHEL 6 it isn't.

Wednesday, October 10, 2012

uninstalling problematic rpms

if you're unable to uninstall an rpm using yum erase/remove or rpm -e because something in the rpm's uninstallation process is broken, try using rpm -e with the --noscripts --notriggers flags:

$ sudo rpm -e sblim-sfcb
/var/tmp/rpm-tmp.54035: line 7: /etc/init.d/sfcb: No such file or directory
error: %preun(sblim-sfcb-1.3.11-0.7.14.x86_64) scriptlet failed, exit status 127
$ sudo yum remove sblim-sfcb
...
Running Transaction
/var/tmp/rpm-tmp.49575: line 7: /etc/init.d/sfcb: No such file or directory

Removed:
sblim-sfcb.x86_64 0:1.3.11-0.7.14

Complete!
$ rpm -qa sblim-sfcb
sblim-sfcb-1.3.11-0.7.14
$ sudo rpm -e sblim-sfcb --noscripts --notriggers
$ rpm -qa sblim-sfcb
$

Monday, July 18, 2011

Python mysqldb UnicodeDecodeError: 'ascii' codec can't decode byte

Solution:

If you run into the error mentioned in the title of this post using python's mysqldb module version 1.2.1 or less, decode your data/query first:

mydata.decode('utf8')

(modifying 'utf8' to whatever encoding your data happens to be in)

Details:

So I was writing some code in python on Ubuntu, and it was working just fine. When I went to run it in RHEL, I got this error:

Traceback (most recent call last):
File "", line 50, in ?
File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 146, in execute
query = query.encode(charset)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 223: ordinal not in range(128)


My first thought was that it was due to the incredibly old version of Python that ships with RHEL 5 (Python 2.4), but it didn't take me long to realize the problem was with the MySQLdb module itself. Ubuntu 10.10 ships with version 1.2.2 of that module, while RHEL 5 ships with version 1.2.1. A minor difference, but apparently in that time this bug was fixed:
http://sourceforge.net/tracker/index.php?func=detail&aid=1521274&group_id=22307&atid=374932

Apparently MySQLdb 1.2.1 tries to indiscriminately encode the data to be put into the database to utf8 (well, at least when you specify utf8 as the database character set), without checking whether the string is already utf8 or not. My solution was just to decode my data from utf8 (to unicode) before passing it to my mysql query, at which point the encoding works just fine.

Like so (the first line's the relevant one):

mydata.decode('utf8')
query = ('INSERT INTO %(database)s (%(column)s) VALUES (%(value)s)' % {'database': database, 'column': column, 'value': mydata})
cursor.execute(query)


Of course, you should modify the 'utf8' part to whatever encoding your data is in.

Edit: If you're using MySQLdb.escape_string(), make sure you run that first before doing the decode, like so:

MySQLdb.escape_string(mydata).decode('utf8')

Wednesday, March 30, 2011

heimdal 1.4 missing lib/otp/version-script.map

I was compiling Heimdal kerberos 1.4 on RHEL 5.6 and got the following error:

/usr/bin/ld: cannot open linker script file ./version-script.map: No such file or directory

After some poking around, it appears that lib/otp/version-script.map is missing from the 1.4 source, which is weird since I downloaded it right from the big "Download 1.4" link from their website (http://www.h5l.org/), which links to http://www.h5l.org/dist/src/heimdal-1.4.tar.gz.

So, to fix the problem, you can download the missing file right from their git repo, here: https://github.com/heimdal/heimdal/raw/e3044663df2cfcafd5bf4e2ea6f2a1ba1503d8ea/lib/otp/version-script.map

Just place it in heimdal-1.4/lib/otp, and you should be good to go.

So the whole process would look something like this:

wget http://www.h5l.org/dist/src/heimdal-1.4.tar.gz
tar xvf heimdal-1.4.tar.gz
wget --no-check-certificate https://github.com/heimdal/heimdal/raw/e3044663df2cfcafd5bf4e2ea6f2a1ba1503d8ea/lib/otp/version-script.map -P heimdal-1.4/lib/otp


...and then you can go on with the configure, make, etc. to build it.

Edit:
Of course if you don't care about OTP (one time password) support, you can just disable this altogether when compiling and not worry about the missing file. Just add the "--disable-otp" flag when running the configure command:

./configure --disable-otp

Saturday, January 22, 2011

Why I'm probably switching from Ubuntu, pt 1 (past)

I feel like I've recently begun a journey, and although I'm not sure where the destination will be yet, I'm pretty sure it doesn't involve Ubuntu. Before I go into why I'm considering switching from Ubuntu, I suppose I should start with how I started using it.

When I started using GNU/Linux (henceforth abbreviated to Linux, cause, well, I'm lazy) in the late 90's, there weren't many options. I tried Red Hat, but even the most basic tasks (like flash or mp3 support) seemed to require a gajillion commands that I frankly wasn't familiar with nor did I have the patience for. I eventually happened upon a copy of Mandrake in a store, and although I didn't use it very much, it became my distro of choice for quite a while. I remember I liked it because it made the simple things relatively simple.

At some point, however, I realized that it wasn't really all that stable. The system would give me problems on a regular basis, and I began looking around at other distributions. Red Hat, while stable, still didn't make life any easier. I tried Debian but couldn't even get past the installation. For a while I dabbled with Slackware, but that was just too much work.

Around this time, Ubuntu came out. Mind you, it seems like a new distribution of Linux pops up nearly every week, and it's been that way for a while, so I didn't pay too much mind to it at first. But then I began hearing things. Good things. Often. Finally, a close friend convinced me to try it out.

It was a bit hard at first to get used to a .deb-based distro (as opposed to .rpm-based). But I soon forgot about that, because what I found was a distribution that was easy to use, with some of the latest software (like Mandrake), pretty stable, and with an ever-growing support community. I've been using it ever since.

I'm using it right now, in fact.

Maybe I'm just slow, but it seems like recently that my path, which has been following the path of Ubuntu for years now, has started to go places that I really don't want do go, however.

And on that note, I'll leave you to ponder where those places might be, until another time.

Thursday, November 18, 2010

UnsatisfiedLinkError exception loading native library: njni11

So... I was working on automating an Oracle 11.1 db installation on a RHEL 5.5 machine. I automated the software install, but when running dbca to create the database, I kept getting this error:

UnsatisfiedLinkError exception loading native library: njni11

I googled it, but all I found were posts on how I needed to make sure I had installed the necessary packages, in particular libaio and libaio-devel. Well, I had all of those installed but I was still getting the error.

It finally hit me: I was automating everything (using Puppet), and hadn't explicitly configured those packages to be installed before Oracle. So they must've somehow gotten installed afterward. The Oracle install still succeeded for some reason, but dbca wouldn't run. Thankfully it was a VM, so I just told puppet to make sure the required packages were installed, reverted to my pre-Oracle-install snapshot, et voila!

Now time to figure out what these listener.ora and tnsnames.ora files are for and how they should properly be configured...