|
|
 slmingol posted this in tips & tricks on January 26th, 2010, @ 8:34 pmBackground
Recently I was trying to create a Ubuntu 9.04 vmware image using Vmware Server 1.08, but I was doing it remotely from my Fedora 10 laptop which was running Vmware Server 1.06. This can normally be done by using Vmware Server’s ability to remotely connect to other Vmware Servers.
 VMware Server Console Here’s my work flow. NOTE: Ubuntu 9.04 will be running on the vmware server on CentOS 5.4.
 VMware Workflow Problem
While going through the setup I encountered a problem I hadn’t seen before where the arrow keys didn’t appear to be working within GRUB while I was installing Ubuntu 9.04.
 broken arrow keys Solution
Turns out there is an option you can enable (i.e. set to TRUE) in the $HOME/.vmware/preferences file which fixes this.
1
| xkeymap.nokeycodeMap = "TRUE" |
NOTE: This change was made to the Vmware Server that was running on the Fedora 10 box.
…. Continue reading → Broken Arrow Keys during an Ubuntu 9.04 install on Vmware Server 1.X »»
slmingol posted this in tips & tricks on September 28th, 2009, @ 11:00 am
Background
A while back I was trying to get the vim textile plugin installed and ran into a problem. Apparently the vim that’s included with Fedora 10, 11, and CentOS 5 doesn’t include ruby support. This bug report explains what’s wrong with vim and how it’s missing ruby support. The problem is visible with this command:
1
2
3
4
| % vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind
...
... |
The –ruby tells us that ruby support isn’t enabled. The only solution I’ve seen thus far is to rebuild vim. Not really a huge deal but it’s work non the less 8-).
Rebuilding vim with ruby support
Here’s how I fixed it.
download vim Source RPM (SRPM)
1
| % wget http://mirrors.xmission.com/fedora/updates/10/SRPMS/vim-7.2.148-1.fc10.src.rpm |
confirm that ruby is installed
1
2
3
4
5
6
| % yum list installed ruby*|column -t|grep ruby
ruby.i386 1.8.6.287-2.fc10 installed
ruby-devel.i386 1.8.6.287-2.fc10 installed
ruby-irb.i386 1.8.6.287-2.fc10 installed
ruby-libs.i386 1.8.6.287-2.fc10 installed
ruby-rdoc.i386 1.8.6.287-2.fc10 installed |
make sure you have your own rpmbuild directory
1
2
3
4
| % mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
# caution with this second command if you already have your own .rpmmacros, this will overwrite!
% echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros |
rebuild vim / re-install vim
1
2
| rpmbuild --rebuild vim-7.2.148-1.fc10.src.rpm
rpm --force -Uvh /root/rpmbuild/RPMS/i386/vim-{c,e,m,X}* |
check that vim now has ruby support
1
2
3
4
| % vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind
...
... |
Ahh. a +ruby means it worked.
Textile Plugin for vim
Now onto installing the vim textile plugin.
First things first, we need to install rubygems
Next we need to install the RedCloth gem, it’s required by the textile plugin
1
2
3
4
5
6
| % gem install RedCloth
Building native extensions. This could take a while...
Successfully installed RedCloth-4.2.2
1 gem installed
Installing ri documentation for RedCloth-4.2.2...
Installing RDoc documentation for RedCloth-4.2.2... |
Finally, install the textile plugin
Downloading the textile plugin from here,
…. Continue reading → Fixing Ruby Support in Vim on Fedora 10, 11, and CentOS 5 & Installing the Vim Textile plugin »»
slmingol posted this in tips & tricks on September 27th, 2009, @ 3:17 am
Now that I’ve been using OpenVZ for several months I’d gotten to the point where I wanted/needed to “yum update” all my VEs. I currently have 11 images running on my OpenVZ Server. I thought I could just vzctl exec … yum -y update all the VEs, but quickly ran into some issues with this brute force approach. Doing the yum -y update broke several of my VEs so I opted to restore the unrecoverable ones from backups.
For my second attempt, I opted to do each VE independently, to get a better understanding of what the best approach would be for doing mass upgrades like this now, and in the future. The first hurdle to overcome had to do with some of the VEs running out of memory (RAM) during the upgrade process.
NOTE: A VE = Virtual Environment (aka. a virtual host), while HN = Host Node
Issue #1, not enough RAM for yum to run
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| # RAM budgets for VEs
# NOTE: values are in # of pages (1 pg. = 4K)
% (printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources)|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 31904 82215 65536 69632 2
/proc/bc/102/resources: privvmpages 119803 196620 166400 179200 9517
/proc/bc/103/resources: privvmpages 27125 35974 65536 69632 0
/proc/bc/104/resources: privvmpages 56251 107250 104960 115200 0
/proc/bc/105/resources: privvmpages 73559 82926 98304 103304 0
/proc/bc/106/resources: privvmpages 30219 68097 65536 69632 0
/proc/bc/108/resources: privvmpages 30081 84291 65536 69632 1
/proc/bc/109/resources: privvmpages 32790 74199 98304 103304 0
/proc/bc/110/resources: privvmpages 40497 69408 65536 69632 1
/proc/bc/111/resources: privvmpages 26990 35371 65536 67840 0
# NOTE: converted the columns to megabytes (MB), it's just easier to read
(printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources|awk '{sub($3,$3*4096/2^20) sub($4,$4*4096/2^20) sub($5,$5*4096/2^20) sub($6,$6*4096/2^20)}1')|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 124.625 321.152 256 272 2
/proc/bc/102/resources: privvmpages 467.98 768.047 650 700 9517
/proc/bc/103/resources: privvmpages 105.957 140.523 256 272 0
/proc/bc/104/resources: privvmpages 219.73 418.945 410 450 0
/proc/bc/105/resources: privvmpages 287.34 323.93 384 403.531 0
/proc/bc/106/resources: privvmpages 118.043 266.004 256 272 0
/proc/bc/108/resources: privvmpages 117.504 329.262 256 272 1
/proc/bc/109/resources: privvmpages 128.086 289.84 384 403.531 0
/proc/bc/110/resources: privvmpages 158.191 271.125 256 272 1
/proc/bc/111/resources: privvmpages 105.43 138.168 256 265 0 |
According to this data 4 of the 11 images had gone over their allocation of RAM. So I tried restarting these and re-running yum update within the problem VEs. Again the update failed and so I needed to increase their allocation of memory. I didn’t want to devote more memory permanently, just a enough temporarily to do the upgrade. So I used this trick to temporarily bump up a VEs allocated memory.
1
2
3
4
5
6
7
8
9
| # increase the RAM by 100MB
vzctl set 101 --privvmpages $((256+100))m:$((272+100))m --save
# ...
# do the upgrade (yum update)
# ...
# decrease the RAM back to the original value
vzctl set 101 --privvmpages 256m:272m --save |
For the remaining 3 VEs that needed additional memory I used these commands to increase their allocations of RAM
1
2
3
4
5
6
7
8
9
| # cmds. to increase RAM by 100MB
vzctl set 102 --privvmpages $((650+100))m:$((700+100))m --save
vzctl set 108 --privvmpages $((256+100))m:$((272+100))m --save
vzctl set 110 --privvmpages $((256+100))m:$((272+100))m --save
# cmds. to decrease
vzctl set 102 --privvmpages 650m:700m --save
vzctl set 108 --privvmpages 256m:272m --save
vzctl set 110 --privvmpages 256m:272m --save |
Issue #2, not enough diskspace for yum to run
The next snag I ran into had to do with a couple of the VEs running out of diskspace. And here’s the commands I used to reconfigure more diskspace.
…. Continue reading → Keeping CentOS 5 OpenVZ images up to Date with Yum »»
slmingol posted this in tips & tricks on September 21st, 2009, @ 10:13 am
Background
I recently saw a post over on Linux Journal that discussed how to glean information about a system’s hard drive, such as its serial number, without having to actually open up the case and physically check it. So I thought I’d take the opportunity to write up a blog post with the specifics of how to do this under Fedora & CentOS, just so I’d have this info handy for future use.
BTW, I was able to accomplish this task several different ways, so this post will cover all the different ways that I could get this info.
Command #1: lshw
This is probably the best tool for getting at a system’s internals. First make sure it’s installed.
For our example you would run the command lshw -class disk:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| % lshw -class disk
*-disk
description: ATA Disk
product: HTS726060M9AT00
vendor: Hitachi
physical id: 0
bus info: scsi@0:0.0.0
logical name: /dev/sda
version: MH4O
serial: MRH403M4GS551Y
size: 55GiB (60GB)
capabilities: partitioned partitioned:dos
configuration: ansiversion=5 signature=cccdcccd
*-cdrom
description: DVD reader
product: UJDA755yDVD/CDRW
vendor: MATSHITA
physical id: 1
bus info: scsi@1:0.0.0
logical name: /dev/cdrom
logical name: /dev/cdrw
logical name: /dev/dvd
logical name: /dev/scd0
logical name: /dev/sr0
version: 1.71
capabilities: removable audio cd-r cd-rw dvd
configuration: ansiversion=5 status=nodisc |
The first section that’s returned is called -disk. Here’s you’ll see the vendor: Hitachi, the product number, HTS726060M9AT00, and my serial number: MRH403M4GS551Y.
Command #2: smartctl
The next tool that would give this type of info is called smartctl. It’s a tool that’s part of the smartmontool package. You may be familiar with the acronym S.M.A.R.T.. The acronym stands for: Self-Monitoring, Analysis, and Reporting Technology. This is a standard that most modern disks have in which vital statistics about a disk drive are provided through a standard API. Here’s how to install it.
1
| yum install smartmontools |
…and once installed you can use the bundled in tool smartctl like so:
…. Continue reading → [one-liner]: Determining a Hard Drive’s Manufaturer Under Fedora 10 & CentOS 5 »»
slmingol posted this in tips & tricks on July 11th, 2009, @ 2:45 am
I’ve been dealing with a nagging problem for several months. The problem? I can’t get my OpenVZ Host Node, aka. HN, to keep consistent time. I’ve even been running ntpd, and the time would still invariably drift so that the HN and the Virtual Environments, aka. VEs, running on the HN were all several hours behind. Simply restarting ntpd would temporarily fix the situation, but I shouldn’t have to do that.
So I finally hunkered down and figured out how to solve this problem. These 2 threads proved extremely helpful in determining the fix.
These threads offered 2 fixes to try. The first, was to modify the ntp.conf file so that any server definitions now included the burst & iburst switches like this:
1
2
3
4
| # /etc/ntp.conf
...
server 192.168.1.6 burst iburst
... |
Adding these switches seemed to help, but then my /var/log/messages log started getting filled with synch attempts by ntpd like these:
1
2
3
4
5
6
7
8
9
10
11
12
| Jul 10 03:50:18 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 03:51:24 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 03:59:59 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:01:21 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:11:52 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:15:05 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:27:56 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:30:06 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:41:53 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:47:17 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 05:03:28 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 05:12:05 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3 |
The second suggestion was the key tip. It recommended that you add a kernel switch called clock=pmtmr to the grub.conf file. Once I tried this I received a warning message in the dmesg log stating that this switch had been deprecated, and the new switch was now clocksource=acpi_pm.
1
2
3
4
5
| % dmesg | grep -i clock
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clock=pmtmr
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clock=pmtmr
Warning: clock=pmtmr is deprecated. Use clocksource=acpi_pm.
Real Time Clock Driver v1.12ac |
So I modified the grub.conf to incorporate the clocksource switch, rebooted the system, and was rewarded with a cleaner dmesg.
1
2
3
4
| % dmesg | grep -i clock
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clocksource=acpi_pm
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clocksource=acpi_pm
Real Time Clock Driver v1.12ac |
A quick check of /var/log/messages looked good, no more ntpd synch messages:
1
2
3
4
5
6
7
8
9
10
11
| Jul 11 00:30:49 mulder ntpd[24578]: ntpd 4.2.2p1@1.1570-o Thu Apr 9 12:53:31 UTC 2009 (1)
Jul 11 00:30:49 mulder ntpd[24579]: precision = 1.000 usec
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface wildcard, ::#123 Disabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface lo, ::1#123 Enabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface veth103.0, fe80::218:51ff:fe43:8487#123 Enabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface vmbr0, fe80::222:15ff:fe91:c12d#123 Enabled
Jul 11 00:30:55 mulder ntpd[24579]: kernel time sync status 0040
Jul 11 00:30:56 mulder ntpd[24579]: frequency initialized 25.118 PPM from /var/lib/ntp/drift
Jul 11 00:42:51 mulder ntpd[24579]: synchronized to LOCAL(0), stratum 10
Jul 11 00:43:54 mulder ntpd[24579]: synchronized to 192.168.1.6, stratum 3 |
Just to be on the safe side, I opted to leave the burst & iburst switches on the server line in the /etc/ntp.conf file. For completeness, I researched what the burst/iburst switches do. Here are those descriptions right out of the ntp.conf man page:
burst – When the server is reachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid with only the server command and is a recommended option with this command when the maxpoll option is 11 or greater.
iburst – When the server is unreachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid with only the server command and is a recommended option with this command.
After waiting for ~2 hours, I still did not see anymore of the ntp synch messages in /var/log/messages. Since the burst/iburst switches don’t seem to be causing any additional problems I’m going to leave them on going forward, and I may remove them completely at a later date. For now, I’m going to wait and make sure that the time remains stable before I do that.
slmingol posted this in tips & tricks on July 10th, 2009, @ 1:16 am
These are some notes on how I was able to get Webex to work on my Fedora 10 laptop. Webex is a java application so to start we need to install java. I usually opt to use the real thing because I’ve never been able to get Ice Tea to successfully work with the webex app.
Installing Java
So to start I download java from java.com. Specifically I downloaded version 1.6u14. This will offer up a file, jre-6u14-linux-i586.rpm.bin. After saving that to disk you need to convert this file to it’s native RPM format. This can be accomplished with these commands.
1
2
3
4
5
| # unpack RPM file
sh jre-6u14-linux-i586.rpm.bin
# install RPM
rpm -Uvh jre-6u14-linux-i586.rpm |
Firefox Java Plugin
Once we have the java JRE installed we need to get the java plugin to be picked up by firefox. This can be accomplished by creating a unix link in firefox’s plugin directory, /usr/lib/mozilla/plugins. Additionally I also usually create a link in my home directory, ~/.mozilla/plugin. I occasionally run into problems where firefox seems to get confused about which plugins are available when I only install them to the firefox’s main system directory, so I’ve just gotten in the habit of installing them in both directories.
1
2
3
4
5
6
7
| # install plugin to firefox's main plugins dir
cd /usr/lib/mozilla/plugins
ln -s /usr/java/jre1.6.0_14/plugin/i386/ns7/libjavaplugin_oji.so
# install plugin to user's firefox plugins dir
cd ~/.mozilla/plugins
ln -s /usr/java/jre1.6.0_14/plugin/i386/ns7/libjavaplugin_oji.so |
At this point do a quick restart of firefox and you should see the plugin under the pull-down, Tools -> Addons, under the plugins tab.
 java plugin added to firefox
…. Continue reading → Setting up Webex under Fedora 10 »»
|
January 26th, 2010, @ 8:34 pm |
Tags: 
Category: 
