urxvt Rainbow

I have used gnome-terminal and terminator, and they are nice. But they are big and bulky. urxvt is nice and small, but it has an ugly default color scheme for at least Fedora 12 and Ubuntu 9.10.
So I wanted to start using urxvt because it seems smaller and faster, but it doesn’t have any menu structure to speak of to make it simple for me to edit the color scheme. Which is fine, it just means I have to find out where the settings are located.
Continue reading

Enabling/Disabling Services in Fedora 12

I have been having trouble with my sshd service.
I use SSH to log in to my home computer and manage things like the hours I work and such, and sometimes when I restart my computer I forget to turn it back on.

But thanks to this site I figured out how to manage services from the command line and now I’ve set both sshd and httpd to start at start-up. Which makes it easier.

But to sum up:
Log in as root with su and then run chkconfig --list to view which services are enabled at which runlevel (runlevels are explained on the linked page). Then to enable services use

chkconfig --level 35 sshd on

specifying runlevels 3 and 5 here and turning the sshd deamon on.

This helps me, now I can’t forget to turn on sshd and my boss won’t have to fear that I might not be able to log in to my home computer so much anymore.

mod_rewrite with Fedora 10 and ISPConfig for WordPress

This relates to Fedora 10 and ISPConfig 3.0.1 set up as described in this HowtoForge post

One of my colleagues recently got interested in offering our clients WordPress as a content management system, so he’s been trying it out.
Yesterday he found out that if he wanted to change the permalink style in WordPress he needed write access to .htaccess, which he didn’t have because the user rights haven’t been set up very well there.
So I gave him write access by using

chown apache:apache .htaccess

Unfortunately this resulted in a 500 Interal Server Error.
Looking at the error log for the website I tried this for it let me know that RewriteEngine directives were not allowed in the .htaccess.
Since I didn’t want to mess with the base configurations of ISPConfig I started looking around for other options. Eventually I found that I had to add something similar to this to the Apache directives field under options under the website’s settings

<IfModule mod_rewrite.c>  <Directory /var/www/[sitename]/web/>    Options +FollowSymLinks    RewriteEngine On    RewriteBase /    RewriteCond %{REQUEST_FILENAME} !-f    RewriteCond %{REQUEST_FILENAME} !-d    RewriteRule . /index.php [L]  </Directory></IfModule>

Of course [sitename] should be replaced with the name of your website.

It all works after I restarted the apache server myself, but I do not know if that is completely necessary. Also it might take a few seconds before ISPConfig finishes editing the configuration file.

Higher Resolution in Fedora 11 with proprietary NVidia Drivers

Ugh… I have been screwing around with this since the beginning of time… Or at least since I installed Fedora for the so-manieth time. Finally though I found out what I had to do.

Following this guide, I was able to easily and correctly install the drivers. I used to build them myself, but that got me worse results then anything.
To sum up, though:

# switch to super user (root)
su

# install rpmfusion repository
rpm -Uvh \http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

# install the driver (I have an i686 pc, you might need a different architecture, like 64_32 or something similar)
yum install kmod-nvidia xorg-x11-drv-nvidia-libs.i586

# reboot to make changed take effect
reboot

This only got me a 1024×768 resolution, though… Which pissed me off…

I started looking around the internet for a way to fix it in the xorg.conf itself, which I’d done on Fedora 9 before, but didn’t remember how (the reason I’m writing this right now), but didn’t actually find what I was looking for.

In the end I found 2 supposed fixes, one added a Modes option to the “Display” section of the “Screen” section, and another was to add a DisplaySize option to the “Monitor” section.
Well, I found out I needed both, so I added DisplaySize 1280 1024 to the “Monitor” section and Modes "1280x1024" to the “Display” subsection of the “Screen” section.

Now it’s working again, running at 1280×1024 with screen compositing (so I can run gnome-do with docky theme, which I’m trying out for a while).

Code::Blocks "process terminted with signal 255 (0 minutes, 0 seconds)"

Yesterday after I came home from work I thought I’d try working on a project I’ve been working on this past weekend.
I was away from home this weekend, so all the work I’d done had been on another computer, in a virtual Ubuntu installation, so I hadn’t yet tried it at home.

Trying to build it went fine. Running it from a terminal went fine. Even compiling and running on another Ubuntu installation (my work laptop, non-virtual) went fine, but Code::Blocks reported to me that whenever I tried running my application on my Fedora 11 home installation that it terminated with signal 255.
I couldn’t find what was wrong, I knew the application worked since I tested it in another terminal window and if I debugged it it’d go great up to the point where it met with a cin or cout.
Being tired from a really long day (getting up at 5:00am, get on train at 6:25am, get off train at 8:30am and at work 8:50am), I gave up fairly quickly.

This morning though the itch got worse and I just had to investigate further.
After about a minute of looking around I found someone at the Ubuntu Forums asking about the exact same thing and it turns out that the problem was that xterm wasn’t installed. So a simple

su -c "yum install xterm"

was enough to fix the problem.

Now I can start developing my application again!

Low Resolution in Fedora 11 with Nvidia drivers

Finally, after hours of looking and working I have finally again found how to set the resolution to what I need (have 1280×1024, had 640×480). I’ve had trouble with my resolution in Fedora before, but I don’t ever remember it being this much of a pain, but then again I don’t remember much about it at all, wish I’d remembered how I fixed it.
So to help me remember and perhaps even help someone else work around it, here’s how I finally got it working.

I’m now using the Nouveau driver with a generic LCD Panel 1280×1024. I tried setting this in

system-config-display

many times, but it just wouldn’t accept my monitor.
So in the end I looked at

system-config-display --help

and noticed

--reconfigure

, which doesn’t base the new configuration file on an old one.
Using this option and setting my driver to nv and my monitor to generic 1280×1024 and then

su -c "init 3"
[log in]
su -c "init 5"

got me the right resolution again. However the nv driver is just a little too basic, so I thought I’d try the same thing with the proprietary driver, so I did everything exactly as before, only I used the driver nvidia instead of nv.
Now again X wouldn’t start at all, so I ran

livna-config-display -a

to get it to my old low-res configuration, and then I tried it a third time, this time using the nouveau driver (which I’ve heard is better then nv) and that worked!

I know that supposedly you’re also able to use xorg.conf to set certain Modes values for your display, but this didn’t do anything for me at all in fedora, did help me in ubuntu, but then there I got the weirdest resolution.

finally I can look at a normal screen again.

Now I should get going to work, I’m gonna be really late (this really bugged me!)

Gfire on Fedora 9

Updating or installing software that does not come from the regular rpm repositories can be a big pain in Fedora. Especially if you don’t have a lot of experience, like me.
I’ve only been using Linux for a few months now, and I don’t have the time to find everything out from the beginning, I’m just doing what I can when I need to.

Now today I wanted to update my version of gfire, since I hadn’t in a while and it had been acting up. Most likely since every time xfire updates it changes something in it’s protocols which make all other things just act wacky.

I went to the website and downloaded the RPM, which started complaining about missing a certain rpmlib. This told me that I might be using an older version of RPM (which I found out after some googling), so I updated my system in the hopes of getting a new version of the RPM package manager, but alas this was not to be.

Found out later in the gfire forums that it was because the RPMs they offer are made for Suse.

Somewhere along this path I had already tried installing it from source, but the source files kept complaining that the pidgin package was not installed, even though it was.

The fix in the end was simple.

If you are having the same troubles as me then just install pidgin-devel and libpurple-devel and try to configure/make/install. This worked for me, it might too for you.

su -c "yum install pidgin-devel libpurple-devel
or
sudo yum install pidgin-devel libpurple-devel

Depending on which you prefer to use.

And then to install gfire from source go to where you extracted the source files (for me this was ‘~/Download/gfire/gfire-0.7.1/’ and type:

su -c "./configure;make;make install"
or
sudo ./configure;sudo make;sudo make install