« Posts tagged Linux

Installing Java on CentOS 5.x

There are a large number of articles floating around with outdated instructions for installing Sun Oracle Java on CentOS. I’m happy to report that the process is now very, very easier if OpenJDK doesn’t work for you.

  1. Browse to this page: http://www.java.com/en/download/manual.jsp
  2. Copy the URL of the “Linux RPM (self-extracting file)” link.
  3. On your CentOS box (assuming you’re SSH’d to it), use wget to download the file (eg, wget http://javadl.sun.com/webapps/download/AutoDL?BundleId=48333)
  4. Note that, when the file finishes downloading you may need to rename it. Due to the redirect process Oracle uses, you may end up with a filename like “jre-6u25-linux-i586-rpm.bin\?AuthParam\=1306440404_3678aad28a7b9aae044da147678b211e\&GroupName\=JSC\&FilePath\=%2FESD6%2FJSCDL%2Fjdk%2F6u25-b06%2Fjre-6u25-linux-i586-rpm.bin\&File\=jre-6u25-linux-i586-rpm.bin\&BHost\=javadl.sun.com” (this happened to me). If this is the case, rename it to “jre-6u25-linux-i586-rpm.bin
  5. Use chmod to allow execute permissions: chmod +x jre-6u25-linux-i586-rpm.bin
  6. Execute the binary: ./jre-6u25-linux-i586-rpm.bin
  7. Verify the installation worked: java -version

That’s it. No extra compiling, no need to add extra repositories. Simple. (Disclaimer: because this is done without a package manager, you’ll have to remember to manually update the installation to keep your box secure.)

Fedora 14: Framebuffer and Xorg in 1680×1050 with Nvidia Drivers

So out-of-box, Fedora 14 does a pretty good job handling graphics, but if you want to run with Nvidia’s drivers you need to do a little leg work. Fortunately, it’s very, very easy if you know your way around the system even a little.

First off, you should download the driver binaries from Nvidia’s site. Save them in an easy-to-access place and then do a quick ‘chmod 777′ on the package so you can execute it later. Also, make sure you have the kernel-headers and kernel-devel packages installed, plus gcc so the Nvidia installer can make the kernel module.

Now that the driver is downloaded, we need to disable the Nouveau driver that comes with Fedora. This is a two-step process.

  1. As root, edit ‘/etc/modprobe.d/blacklist.conf’ and add the following lines to the bottom:
  2. # Nouveau
    blacklist nouveau

  3. Now edit ‘/boot/grub/menu.lst’ and add the following to the end of the kernel line:
  4. nouveau.modeset=0
    e.g, “kernel /vmlinuz-2.6.35.9-64.fc14.x86_64 ro root=UUID=00311e4e-0043-498c-8532-7301b19eae76 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet nouveau.modeset=0

With that done, reboot. As your computer boots, press the Tab key repeatedly before the Fedora splash screen appears to get the Grub Menu to appear. Press ‘a’ to do a one-time edit of the kernel options (you’ll see the line above appear) and add the number ’3′ (no quotes) to the end, like so:

kernel /vmlinuz-2.6.35.9-64.fc14.x86_64 ro root=UUID=00311e4e-0043-498c-8532-7301b19eae76 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet nouveau.modeset=0 3

This will do a one-time boot to Run Level 3, much like adding ‘single’ to the end of the above line would put you in to Single User Mode. Once you’re at the text-mode long prompt (at a really low screen resolution, I might add), login as root and browse to the folder you saved the driver binary to, then run it. Let it go through it’s process and create the files it wants to, and when it finishes, you’re almost done.

The last thing to do is make the framebuffer work on the correct resolution. In my case, my monitor uses 1680×1050 as it’s native resolution, so that’s what I want to set it to.

Reboot the computer again, and do the Tab key trick to get back to the Grub Menu. Once again, press ‘a’ to edit the kernel options and this time add ‘vga=ask’ in addition to the number ’3′ to the end of the line, and then press enter. You should get a list of the framebuffer modes. Find the one that matches your resolution, enter it (and make a note of it), and then press enter. When you get to the login prompt, you should see that everything is the correct size and resolution. If not, try again. For reference, 1680×1050 in 32bit colour for my GeForce 260 is mode 369.

Once you have the correct mode, we’re ready to make it permanent. Login as root and edit the ‘/boot/grub/menu.lst’ file again. Now add the following to the end of the kernel line:

vga=873 video=nvidiafb

eg, kernel /vmlinuz-2.6.35.9-64.fc14.x86_64 ro root=UUID=00311e4e-0043-498c-8532-7301b19eae76 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet nouveau.modeset=0 3 vga=873 video=nvidiafb

Where 873 is the the mode you entered above converted from hex to decimal (369 hex == 873 dec).

Save, reboot, and watch as both the framebuffer and Xorg now work at the proper resolution for your monitor. You’ll also now be able to turn on Desktop Effects in Gnome if you so choose.

IPTABLES Logging on a VPS

When you manage a *nix-based server, there are a few general guidelines that most admins follow; Doing things like setting a strong root password, changing SSHD to a non-standard port, and setting up logging are usually firsts. However, if you’re on a VPS, you may run in to a few issues (note that these instructions are for CentOS 5.x and may vary depending on your distro).

For example, when I was setting my the nice new VPS that I’m running this site from I attempted to enable IPTABLES logging to monitor attempts to get to the standard SSH port (22), and the port that I actually use for SSH (I won’t post the real one, but for the example I’ll use port 1234) with the following lines in “/etc/sysconfig/iptables”:

<Snip other rules>
-A INPUT -m state --state NEW -p tcp -m tcp --dport 1234 -j LOG -m limit --limit 20/m --log-level warn --log-prefix "SSH Attempt on port 1234: "
-A INPUT -p tcp -m tcp --dport 1234 -j ACCEPT
<Snip even more rules>
-A INPUT -p tcp -m tcp --dport 22 -j LOG -m limit --limit 20/m --log-level warn --log-prefix "Dropped SSH on port 22: "
-A INPUT -j DROP
Note that you need to add the LOG lines before the ACCEPT and DROP lines.  Only 20 lines will be logged per minute to prevent file sizes from going nuts in case of an attack.
After restarting IPTABLES with service iptables restart, I made a few access attempts and checked /var/log/messages — no log lines appeared, though. Then I realized I was missing something.
In “/etc/syslog.conf” I had to add the following to the end:
kern.=warn   /var/log/firewall
I opted to log to firewall instead of messages simply to keep the file clean.
I restarted SYSLOG with service syslog restart, made a few more attempts, and still nothing was appearing in “/var/log/firewall” or “/var/log/messages”. However, typing dmesg showed the relevant lines:
SSH Attempt on port 1234: IN=venet0 OUT= MAC= SRC=10.0.0.1 DST=10.0.0.2 LEN=48 TOS=0×00 PREC=0×00 TTL=116 ID=28979 DF PROTO=TCP SPT=35291 DPT=1234 WINDOW=8192 RES=0×00 SYN URGP=0
So I knew that SYSLOG was working, however it wasn’t going all the way. Then I decided to see if KLOGD was running:
[root@vps ~]# ps aux|grep klogd
root     13632  0.0  0.1   7188   788 pts/0    S+   00:07   0:00 grep klogd
So that means that KLOGD isn’t running, which is the cause of the problem! I checked “/etc/rc.d/init.d/syslog” and found that the KLOGD lines were commented out, as such:
<snip>
passed klogd skipped #daemon klogd $KLOGD_OPTIONS
<snip>
passed klogd skipped #killproc klogd
In the “start()” and “stop()” areas respectively. I simply removed the “passed klogd skipped #” parts, saved and ran service syslog restart and presto, KLOGD was up and running:
[root@vps ~]# ps aux|grep klogd
root      7542  0.0  0.0   3808   424 ?        Ss   Oct11   0:00 klogd -x
root     15402  0.0  0.1   7188   788 pts/0    S+   00:13   0:00 grep klogd
I made a few more connection attempts and verified that now everything was working correctly:
[root@vps ~]# cat /var/log/firewall
Oct 11 23:47:06 vps kernel: SSH Attempt on port 1234: IN=venet0 OUT= MAC= SRC=10.0.0.1 DST=10.0.0.2 LEN=48 TOS=0×00 PREC=0×00 TTL=116 ID=28979 DF PROTO=TCP SPT=35291 DPT=1234 WINDOW=8192 RES=0×00 SYN URGP=0
Oct 12 00:13:03 vps kernel: Dropped SSH on port 22: IN=venet0 OUT= MAC= SRC=110.77.129.166 DST=10.0.0.2 LEN=60 TOS=0×00 PREC=0×00 TTL=45 ID=59383 DF PROTO=TCP SPT=33846 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0
Done and done! IPTABLES now properly logs to “/var/log/firewall” when someone attempts to hit port 22 or 1234.
TL;DR Version: If you want IPTABLES logging enabled on your VPS, follow the normal steps to enable IPTABLES logging and then make sure KLOGD is enabled in  ”/etc/rc.d/init.d/syslog”.

Fixed: Can’t Resize Uploaded Images in WordPress

Here’s one with an easy fix. If you’ve just installed WordPress on your server and can upload images but WordPress doesn’t let you resize them in the same form, SSH in to your server and do the following:

yum install php-gd

service httpd restart

And you’re done! …At least, as long as you’re using an RHEL-compatible Linux distro. If not, use your package manager of choice, or manually find and load the php-gd extension!

Android: Force Terminal Emulator to Open the BASH Shell as Root

Important! This article assumes that your phone is rooted. If you don’t know what that is or how to do it, this article won’t be able to help you. If your phone isn’t rooted, this won’t work.

I love my Android phone, but the root side of it still has some quirks. The default shell, for example, is pretty bare-bones. Fortunately, there are ROMs out there like CyanogenMod that help with that side of things by providing little extras like, for example, the BASH shell. BASH is incredibly handy on an Android phone as the default shell doesn’t allow you to scroll back through your command history using the track ball.

So while BASH is included in some ROMs, it’s not the default shell. Typically, I’ve been using ConnectBot (available on the Android Market) which works well, however I’d usually end up starting out every session like this:

su -c bash

It’s only one line, but really, it’s annoying to have to type it out every time. I’m in the IT field, so my nature is to be lazy and automate everything. Enter Terminal Emulator.

Available for free from the Android Market, Terminal Emulator is very basic. It doesn’t allow you to SSH to remote systems or anything like that – instead, it just immediately opens a local shell. As an added bonus, the preferences let you specify the Command Line to the shell executable.

I thought this was my answer. I set the Command Line preference to “/system/xbin/bash -” (the location on CyanogenMod 5.x.x — this may differ depending on your ROM. Make sure the path is correct before hand, as if you set it incorrectly it’s nearly impossible to get Terminal Emulator back up and running) and re-launched it.

Success! I was in the BASH shell! However, I wasn’t root, and this did cause a problem. As soon as I typed su to become root, my shell was changed back to the default one. After doing a little more digging, though, I found my solution.

In the Terminal Emulator preferences, there’s another option for Initial Command - Terminal Emulator will execute this immediately on open. So, I inserted the line I was using in ConnectBot (su -c bash) and voilà! Terminal Emulator now immediately opens with a BASH shell as root.

The TL;DR version: Install Terminal Emulator from the Android Market, open it, hit the Menu button, then Preferences. Tap Initial Command and enter “su -c bash” — now it will always open with BASH running as root.

Extra Note: If you are using an Android phone without a physical keyboard, simply hold the Menu button on your phone for a few seconds in Terminal Emulator to force the virtual keyboard to appear.

UPDATE: As it turns out, you can do this in ConnectBot as well. Tap-and-hold on the local connection, then choose ‘Edit Host’ and ‘Post-login automation’. Note that if you do this, though, ConnectBot will enter the command, but you still have to press enter to active it.

Short: Quantum Linux

Due to a failed kernel upgrade earlier today, I decided to wipe my MSI Wind and start over with the LXDE spin of Fedora 12. After the install, I went through installing my favourite packages, and notice the following while yum processed the dependencies for VLC:

schroedinger   i686   1.0.8-3.fc12   updates   208k

Closer inspection revealed the package to be a codec, but that only led to further questions. Does this package transport video, and then only determine whether it is encoded/decoded when your media player first tries to render it? Does the process involve acid, or radioactive material? Does it work with Boxee?

This has been your annual dose of quantum humour. I now return you to your Superbowl Sunday. Thank you.

Short: MSI Wind U123 and Fedora 12 Wifi

My MSI Wind U123 has an 802.11n wifi card that uses the Ath9k driver. Although it’s technically supported by the 2.6.31 kernel used by Fedora 12, it constantly drops it’s signal and often refuses to connect to my access point.

I’m happy to report, however, that after I manually compiled the 2.6.32 kernel and booted with it, the wireless card works perfectly!

Unfortunately, it seems the 2.6.32 kernel also breaks a few things – booting takes 3 minutes, and the machine hard locks on with a black screen if you close the lid. I’m going to try to iron out those issues, but overall I’m pleased with the results.

Edit: I re-installed Fedora 12, then updated to the 2.6.32.1 kernel using the FC13 rpm’s from http://mirror.kernel.org – works like a charm now. I still can’t close the lid unless I have the action set to ‘do nothing’, but I can deal with that.

Additional Edit (02/15/2010): I’ve enabled the Rawhide repo and set it to only include kernel* and dependencies. The 2.6.33 RC chain works perfectly.

Short: NetworkManager, Bah!

I have a love-hate relationship with NetworkManager on Fedora. I love it on my netbook for the ease it provides when trying to connect to wireless networks. However, I hate it on my dual-NIC workstation at work as it always mangles the connections and tries to route traffic through eth1 when eth0 is the primary network. As such, my favourite commands of the moment are:

chkconfig NetworkManager off

chkconfig network on

Then, a quick change to

/etc/resolv.conf

/etc/sysconfig/network-scripts/ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth1

in order to add the correct nameservers, gateway, and IP addresses, and life is good!

MSI Wind/Fedora 12 Beta – Still Pulsing (Updated)

I like bleeding-edge technology. The newer, the better, as there are usually fun little things to discover and rarely does anything bleeding-edge actually work perfectly, giving me ample opportunity to mess around with things.

Enter Fedora 12. I’ve played with the initial Alpha release, several of the Snap releases, and as of this morning, the Beta release. So far, at least as far as my MSI Wind 123 goes, they’re all unusable.

The biggest problem so far is the display – as soon as GDM kicks in, prior to the login screen loading, the screen starts to ‘pulse’. To be more specific, if you were to tap the ‘Brightness Up’ and ‘Brightness Down’ keys fairly quickly between two different levels, you’d get the same effect. This continues incessantly, and makes it impossible to use the GUI. If I boot in runlevel 3 (direct-to-console), everything is fine, so the issue is restricted to Xorg.

As far as the beta goes, there’s been a little regression. In the Alpha and Snap releases, I was able to get all the way to the desktop, despite the pulsing display. Now, with the beta, it takes just over 2 minutes just to get past the boot animation, and then it stalls before the login screen loads. Whether or not this has anything to do with the fact this is a livecd on a USB stick (made with the Fedora live-usbcreator for Windows, with persistent overlay), I’m not sure. I’ll probably download another spin (maybe the KDE version) and see if I have any more luck.

Update: Progess! On a whim, I removed rhgb from the kernel line when booting (press Tab to cancel automatic boot, and then again to edit boot options) and was actually able to get to the desktop, albeit with no improvement to the speed of things. The screen still pulses, however I did notice something interesting: while the screen pulses (briefly before the login screen appears, then it stops until you choose a user, and then it starts again), if I switch to another terminal (CTRL+ALT+F2, for example), the login name starts to fill with “^@” repeated several times, and then stops. If I then switch back to the GDM terminal (CTRL+ALT+F1), the pulsing stops.

At least that gives me something to go on.

Further Update (Dec 12, 2010): The Wind U123 works perfectly on Fedora 14 with no additional hacks/changes needed.

Moblin 2 Beta: A Step in the Right Direction (Updated)

And while it may be a step in the write direction, there are a few little things that just bug me about the current iteration of the Moblin netbook distribution.

  • Power Button – Where is it? The short answer is there isn’t one – your only option is to simply use the physical power button on your netbook. Also, the shutdown terminal command is strangely absent. Thankfully, though, the reboot command is still there. It would be excellent if Shutdown/Reboot/Sleep were included in the options presented when you click the battery status icon.
  • myzone – There’s no way to customize the myzone tab, which is the default location on start up. You get three columns, and no control of them or choice in adding other quick content. Not very handy for a start page, in my opinion.
  • Persistence – The detailed instructions page that tells you how to put Moblin on a flash drive/SD card/whatever doesn’t explain how to add a persistence layer so that your changes survive a reboot. All of the instructions/utilities supplied simply bite-copy the image to your device and that’s that. Supposedly you can use the Fedora LiveUSB Creator to do this, but I’ve yet to try it. Having an official utility would help, and something that I hope to see coming down the road.

So for the time being, Moblin is something that’s neat to play around in – it has an amazing interface that’s refreshing and definitely easy to use for Linux (or computer-in-general) newbies – but still has some growing to do before I’d use it in place of a full distribution.

With any luck, they’ll work on these things for the final version of Moblin 2, or if not that, than hopefully for Moblin 3.

Edit: Also useful information, the root password for Moblin 2 is ‘moblin’. And for some reason, although sudo is installed by default, the standard user (also ‘moblin’) isn’t in the /etc/sudoers file, so you can’t use sudo unless you manually add it. That needs to get fixed as well.