|
|
 slmingol posted this in tips & tricks on September 28th, 2009, @ 11:00 amBackground
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 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 »»
slmingol posted this in tutorials on June 20th, 2009, @ 2:18 am
Setting up a RAID can be a tricky proposition. But once you’ve gone through a couple of times it isn’t really all that hard to master. Below are some screenshots from a CentOS 5 build I recently went through to help explain how one can go about setting up a RAID-1 using 2 60GB drives. RAID-1 is 2 drives mirroring each other. I should mention that these directions should be directly applicable to a RHEL system as well as a Fedora system too.
Getting Started
First things first you need to boot the system using a CentOS DVD. Eventually you’ll get to the point where you’ll need to partition the drives, and you’ll be presented with the following screen.
 initial screen - setting up partitions Setting up the Primary Drive for the OS
Initially we need to go through and remove any pre-existing partitions that may exist on the drives. In our setup we have 3 drives. 1 is for the OS, and the other 2 drives are going to make up our RAID-1.
Here I’m removing the pre-existing partition on the hda drive, aka. the one that the OS will be installed to.
 removing hda's existing partitions I’m going to skip a bit here, but suffice to say that all I did was create a default setup of partitions on hda.
…. Continue reading → Setting up a RAID During a CentOS 5 Installation »»
slmingol posted this in tutorials on May 20th, 2009, @ 1:51 am
This tutorial sets up and configures the following:
Primary packages
- sendmail
- spamassassin
- milter-greylist
- GeoIP
- clamav
- spamassassin-milter
- clamav-milter
- dovecot
Addons to spamassassin
Optional Extras
NOTE: I’ll discuss how to setup the spf-milter, towards the end of this post but I now consider this an OPTIONAL package after talking with the maintainer of the city-fan.org repo, Paul Howarth. In talking with Paul, it turns out that spamassassin now has the ability to perform SPF checks based on a sender’s domain and IP address. This makes installing the spf-milter redundant and unecessary.
Getting Started
I found this very helpful YUM repository, city-fan.org that contains pretty much everything I needed to accomplish this, minus the ClamAV packages. For those I looked to another repository, rpmforge. To get started, I installed the repo rpm files below.
Setting up city-fan.org repo
1
2
3
4
5
6
7
8
| # install yum repo package
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-1-7.rhel5.noarch.rpm
# import repo's GPG Key
rpm --import http://www.city-fan.org/ftp/contrib/yum-repo/CITY-FAN.ORG-GPG-KEY
# perform an initial update
yum update |
Setting up rpmforge repo
1
2
3
4
5
6
7
8
| # install yum repo package
rpm -Uvh http://dag.wieers.com/rpm/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
# import repo's GPG Key
rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
# perform an initial update
yum update |
Setting up Spamassassin
1
2
| yum install spamassassin \
spamass-milter |
Setup /etc/sysconfig/spamassassin
1
2
| # Options to spamd
SPAMDOPTIONS="-d -c -m5 -H" |
Setup /etc/sysconfig/spamass-milter
1
2
3
4
5
6
7
8
9
10
11
12
| ### Override for your different local config
#SOCKET=/var/run/spamass-milter/spamass-milter.sock
### Standard parameters for spamass-milter are:
### -P /var/run/spamass-milter.pid (PID file)
###
### Note that the -f parameter for running the milter in the background
### is not required because the milter runs in a wrapper script that
### backgrounds itself
###
### You may add another parameters here, see spamass-milter(1)
#EXTRA_FLAGS="-m -r 15" |
Add the following to sendmail.mc and re-make sendmail.cf
1
2
3
4
5
6
| dnl **
dnl ** enable spamassassin-milter to scan for spam using spamassassin **
dnl **
INPUT_MAIL_FILTER(`spamassassin', `S=unix:/var/run/spamass-milter/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}')dnl |
Setting up SPF (NOTE: used by spamassassin, NOT the milter!)
1
2
3
4
5
| # install perl-Mail-SPF
yum install perl-Mail-SPF
# restart spamassassin (in order to detect the spf plugin)
/etc/init.d/spamassassin restart |
Spamassassin will automatically detect that SPF has been installed and will start using it as part of its scoring of each email. You can confirm that it’s working with this test.
1
2
3
4
5
6
7
8
9
10
11
| spamassassin -D < /usr/share/doc/spamassassin-3.2.5/sample-spam.txt 2>&1 |grep -i spf
[18108] dbg: config: read file /usr/share/spamassassin/25_spf.cf
[18108] dbg: config: read file /usr/share/spamassassin/60_whitelist_spf.cf
[18108] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC
[18108] dbg: spf: checking to see if the message has a Received-SPF header that we can use
[18108] dbg: spf: using Mail::SPF for SPF checks
[18108] dbg: spf: no suitable relay for spf use found, skipping SPF-helo check
[18108] dbg: spf: already checked for Received-SPF headers, proceeding with DNS based checks
[18108] dbg: spf: no suitable relay for spf use found, skipping SPF check
[18108] dbg: spf: def_spf_whitelist_from: already checked spf and didn't get pass, skipping whitelist check
[18108] dbg: spf: whitelist_from_spf: already checked spf and didn't get pass, skipping whitelist check |
Setting up DKIM
This module implements the various components of the DKIM and DomainKeys message-signing and verifying standards for Internet mail. It currently tries to implement these specifications:
* RFC4871, for DKIM
* RFC4870, for DomainKeys
1
| yum install perl-Mail-DKIM |
Spamassassin will automatically detect that DKIM has been installed and will start using it as part of its scoring of each email. I confirmed that it was working by sending myself an email from my gmail account and copying this email, make sure to include the full headers, into a text file. In my case I called this file test_email.txt.
1
2
3
4
5
6
| spamassassin -D < ~/sam2.txt 2>&1 |grep -i dk
[18334] dbg: config: read file /usr/share/spamassassin/25_dkim.cf
[18334] dbg: config: read file /usr/share/spamassassin/60_whitelist_dk.cf
[18334] dbg: config: read file /usr/share/spamassassin/60_whitelist_dkim.cf
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
bh=8PW6kvDkcUGo7mGimEUrTlMVS5Y1dFw/IjjLn1WnNLw=; |
Setting up GeoIP
This package will be leveraged by milter-greylist to perform greylisting based on geographic locations of the sender’s IP address.
Setting up milter-greylist
The latest version can be downloaded from this page
1
2
| wget http://www.mailscanner.info/files/greylist/milter-greylist-4.0-4.jkf.el5.i386.rpm
yum --nogpgcheck install milter-greylist-4.0-4.jkf.el5.i386.rpm |
…. Continue reading → How to Setup a Mail Server on CentOS 5 »»
slmingol posted this in tips & tricks on May 19th, 2009, @ 8:54 pm
Now that I’ve been using OpenVZ for several months I thought it would be a good time to devote a few cycles to putting together a backup routine for the 10+ OpenVZ VEs that I’ve setup. Here is the procedure I put together to backup one of my VEs. I should mention that all my VEs make use of automounts, and through experimentation I figured out that I need to stop the automounter while I’m performing a backup of a VE. From my HN I determined that this was the minimal number of commands I could accomplish a backup of a single VE.
1
2
3
4
| vzctl exec 101 /etc/init.d/autofs stop # stop automounter
vzdump --compress --suspend 101 # backup VE(Virtual Environment) 101
vzctl exec 101 /etc/init.d/autofs start # start automounter
mv vzdump-101.log vzdump-101.tgz /mnt/vz_backups/ # move backed up file to on-line storage area |
Here is the full transcript from a backup
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
| % vzctl exec 101 /etc/init.d/autofs stop
Stopping automount: [ OK ]
% vzdump --compress --suspend 101
INFO: Starting new backup job - vzdump --compress --suspend 101
INFO: Starting Backup of VM 101 (openvz)
INFO: status = CTID 101 exist mounted running
INFO: starting first sync /vz/private/101 to /var/tmp/vzdumptmp22651
INFO: Number of files: 35178
INFO: Number of files transferred: 25940
INFO: Total file size: 800591555 bytes
INFO: Total transferred file size: 616512883 bytes
INFO: Literal data: 616512883 bytes
INFO: Matched data: 0 bytes
INFO: File list size: 712364
INFO: File list generation time: 0.001 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 618585522
INFO: Total bytes received: 679718
INFO: sent 618585522 bytes received 679718 bytes 10069353.50 bytes/sec
INFO: total size is 800591555 speedup is 1.29
INFO: first sync finished (61 seconds)
INFO: suspend vps
INFO: Setting up checkpoint...
INFO: suspend...
INFO: get context...
INFO: Checkpointing completed succesfully
INFO: final sync /vz/private/101 to /var/tmp/vzdumptmp22651
INFO: Number of files: 35178
INFO: Number of files transferred: 0
INFO: Total file size: 800591555 bytes
INFO: Total transferred file size: 0 bytes
INFO: Literal data: 0 bytes
INFO: Matched data: 0 bytes
INFO: File list size: 712364
INFO: File list generation time: 0.001 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 716728
INFO: Total bytes received: 4363
INFO: sent 716728 bytes received 4363 bytes 480727.33 bytes/sec
INFO: total size is 800591555 speedup is 1110.25
INFO: final sync finished (1 seconds)
INFO: resume vps
INFO: Resuming...
INFO: vps is online again after 3 seconds
INFO: creating archive '/vz/dump/vzdump-101.dat' (/var/tmp/vzdumptmp22651/101)
INFO: Total bytes written: 641587200 (612MiB, 11MiB/s)
INFO: file size 201MB
INFO: Finished Backup of VM 101 (00:02:02)
% vzctl exec 101 /etc/init.d/autofs start
Starting automount: [ OK ]
% mv vzdump-101.log vzdump-101.tgz /mnt/vz_backups/. |
I put together this one-liner which will handle the backing up of all 11 of my VEs.
1
2
| for i in `seq 101 111`;do vzctl exec $i /etc/init.d/autofs stop; vzdump --compress --suspend $i; vzctl exec $i /etc/init.d/autofs start;done
mv vzdump-*.tgz /mnt/vz_backups/. |
|
September 28th, 2009, @ 11:00 am |
Tags: 
Category: 
