Archive
You are currently browsing the archives for the centos category.
By cormander
So I mentioned in a previous post that even after lzma and xz support are added to centos5’s version of RPM (4.4.2.3 + heavy patches), installing stuff from fedora 12 return an error about the md5sum.
Well, after looking through the code, the use of “md5sum” is misleading because rpm supports multiple types of checksums. This error is actually changed in a later version of RPM where they have done a really good job cleaning up the code base. But more on that another time.
The fedora project’s wiki contains information about the desire for stronger hashes in the rpm files, and this goal has been obtained as of fedora 11. They made the jump from sha1 support (which exists in centos5 rpm) to sha256, breaking backwards compatibility. I’m a bit annoyed by this. I don’t disagree with the decision to use a stronger hashing algorithm for checksums, but I disagree with the statement that “the necessary rpm backport would be too large”.
C’mon, RedHat! You know very well lots of people pull the latest fedora sources and rebuild them on RHEL. I can understand not bothering to port it in older versions of fedora, but give me a break. Don’t make me go and do your job for you.
I very well may have to, however. Although it now works where I can install an RPM with my lzma patch, I have to pass –nomd5 on the command line to install it, which I don’t exactly find to be acceptable. Sure, security is already done in the gpg checking, but you lose the file integrity checking.
If I can manage to find a src.rpm development version of rpm for the next RHEL5, I’ll have a peek in there to see what is new. If nothing points in this direction… time to crack open the source code again.
By cormander
When fedora 11 started development, I noticed that pulling in the .src.rpm files and rebuilding them on centos5 wasn’t so straight forward. Long story short, beginning in fedora 11 (and more so in fedora 12) the RPM files started to be compressed by lzma and xz, which exist in the xz compression package.
My way around this since then was to install the xz package (built from source on centos 5) onto my machine and extract the contents of an rpm file like so:
$ rpm2cpio xxxx.rpm | xz -d | cpio -id
This lets me get the contents of the rpm (source or binary). However, this didn’t always work because they were not always xz or lzma compressed, and is quite annoying. This also doesn’t let me install stuff from fedora 12 into a chroot on a centos 5 host, which has really been bugging me recently.
So, I cracked open the source and did some searching on google. I came accross a lzma patch for rpm by debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509444
This, however, didn’t go straight into centos5’s version of rpm, and didn’t support xz compression. After a few hours of tinkering though, I was able to get it to go in cleanly, compile, and work with xz as well. The only catch is, it adds the requirement of xz-libs to install and xz-devel to build. Not such an issue for me.
For anyone interested, here is the patch:
http://rpm.cormander.com/patches/rpm-4.4.2.3-rpmio-lzma.patch
It goes in right at the end of the patches inside rpm-4.4.2.3-18.el5.src.rpm as patch number 51.
Here is an example of the current centos5 rpm attempting to unwrap a fedora 12 rpm:
[corman@localhost ~]$ rpm2cpio kernel-2.6.31.5-127.fc12.x86_64.rpm | file -
/dev/stdin: xz compressed data
After here we are again after installing the patched rpms:
[corman@localhost ~]$ rpm2cpio kernel-2.6.31.5-127.fc12.x86_64.rpm | file -
/dev/stdin: ASCII cpio archive (SVR4 with no CRC)
So one problem is gone. The last problem I’m facing now is md5sum mismatches, so my install into a chroot via yum still won’t work yet:
error: unpacking of archive failed on file /etc/fedora-release;4b9207ac: cpio: MD5 sum mismatch
It’s pretty late so I’ll see if I can figure that out another day. If I do figure this md5sum mismatch out, I’ll update the above patch and also include the centos5 rpm rpms patched with this in my rouge-beret repo.
By cormander
So I’ve started working on a default RBAC policy for centos 5 servers. A secure default policy that works out of the box with the operating system is a big incentive to use the grsecurity kernel, and that is what I am aiming for.
To make things easier, it turns out that you can include policies from directories. This wasn’t indicated in the documentation that I’ve read, and the syntax is odd so I wasn’t able to figure it out on my own, but it goes like this:
include </etc/grsec/somedir>
Each file in the directory (if any) is parsed as a policy. This will make things easier for a distribution to drop in policy files for its applications.
I’m going to make an RPM for centos 5 for this, as part as my rouge-beret project. I’m thinking I’ll call the package rouge-beret-rbac and it’ll have the gradm package as a dependency. I’m going to do something like this at the end of my default policy configuration:
include </etc/grsec/default>
include </etc/grsec/domains>
include </etc/grsec/users>
include </etc/grsec/groups>
That way, you don’t have to edit the policy file and worry about edits getting stomped when the package updates.
In addition, my RPM with this policy will have an init script to automatically enable the RBAC policy at the completion of boot, which will happen depending on a value set in /etc/sysconfig/grsec-rbac.
If I’m lucky I’ll get this all put together by the end of this weekend. Here is a link to the git repo I created for this:
http://git.cormander.com/?p=rouge-beret-rbac.git;a=tree;f=etc/grsec
By cormander
Just real quick, here is a set of patches I wrote a few days ago in order to get the latest version git (currently 1.6.4.4) to compile on my CentOS 5 machine. You can download this source from the Git Website, apply and commit these patches, and “make rpm”. Make sure you have things such as curl-devel and asciidoc installed. Use the rpmforge rpm for its yum repo for the asciidoc package.
Now I’m not saying these are the best solutions, but they are the quick-and-dirty things to get it to compile. They both address asciidoc issues, and I’m not inclined to chase them down any further at this point in time.
Patch #1
Fix file:// URL wrapped in +++; apparently older versions of asciidoc don’t like this. Oh well? This patch seems to fix the issue
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -374,7 +374,7 @@ objects until you tell it to. First make sure that:
Then there are two ways to get a smaller repository. A safer way is
to clone, that keeps your original intact.
-* Clone it with `git clone +++file:///path/to/repo+++`. The clone
+* Clone it with `git clone file:///path/to/repo`. The clone
will not have the removed objects. See linkgit:git-clone[1]. (Note
that cloning with a plain path just hardlinks everything!)
Patch #2
Old versions of asciidoc complain about unsafe content
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -40,7 +40,7 @@ man7dir=$(mandir)/man7
# DESTDIR=
ASCIIDOC=asciidoc
-ASCIIDOC_EXTRA =
+ASCIIDOC_EXTRA = --unsafe
MANPAGE_XSL = manpage-normal.xsl
XMLTO_EXTRA =
INSTALL?=install
Hope this helps someone else out.
By cormander
I’ve been working a lot with Tim Post these past few months of various things. He’s been a great mentor among other things. One thing that he is (that I am not) is a debian guy. This works well for the both of us, since I’m a RedHat guy and he isn’t. This creates quite the dynamic between the two of us on how we approach different issues.
One of the things we’ve been working to get going is gridnix, a linux distribution of our own. I’ve pulled Tim in my direction enough to be OK with the idea of using RHEL as a base for the OS, with our own various packages on top of it (and replacing some of the base os, such as coreutils). To this end, I’ve put together my Red Beret yum repo, to use for both gridnix and anyone else in the RHEL/CentOS community who would like to use these updated packages.
I, however, have been unable to pull him all the way in. He refuses to use yum, all for reasons I don’t have a good counter for. So I’ve decided to settle, and agree to use apt’s rpm port. So I looked to Dag Wieers’ site, since he’s the (perhaps only) CentOS core developer who uses apt. I read through his apt tutorial using apt in an rpm world and got myself up with it. So far so good.
This reminds me of what Scott Shinn has to say about the whole thing … he likes to joke that Dag has been converted to the dark side, since he’s kept yum at arm’s length. Well, turns out I’m headed in his direction. The apt utility has a lot of advantages over yum.
By cormander
For years I’ve built my own RPMs and have shared so few of them. This hasn’t been because I didn’t want to, just that I haven’t really had the resources (hosting space, a cluster of build machines, time). Well now I’ve finally got all of the above to some extent, and with some additional organization I put in this week, I have put together the Red Beret Yum Repository (http://rpm.cormander.com/repo/).
As of right now only the “testing” repository has anything in it, and only el5 for now, but it’s a work in progress. As soon as I feel that everything in there is ready to be pushed to the production repo I will. Moving forward I’ll have el4 in there, and then possibly start to build these packages for fedora as well.
You might also notice the “grsec” directory in there. I’ll be moving my grsecurity kernel packages into there from now on, and I’ll only be keeping up with the latest kernel (no more backports for 2.6.24, sorry guys, it just takes way too much time for one guy).
By cormander
Sometimes you want something to run at boot, but you can’t use chkconfig because you haven’t written a full blown sysvinit-sytle script to facilitate the operation. You’d probably just want to add it to rc.local, but perhaps you want it to run before a certian sysviinit-style script, for example, before the network starts or before apache starts? The rc.local can’t do this, since it’s ran last.
Well here is a quick way to add a custom script to the boot process w/o too much work. Since I have to do this on occasion, I thought I’d post about it.
First you cd into your rc.d directory:
[root@localhost ~]# cd /etc/rc.d/
Now create your script in your favorite editor (or just copy it here):
[root@localhost rc.d]# vi rc.myscript
Don’t forget to make it executable!
[root@localhost rc.d]# chmod +x rc.myscript
Now create a link to it in /etc
[root@localhost rc.d]# cd ..
[root@localhost etc]# ln -s rc.d/rc.myscript ./
Now add it to each runlevel you want it to run in. You probably care most about runlevel 3 and 5:
[root@localhost etc]# cd rc3.d/
[root@localhost rc3.d]# ln -s ../rc.myscript S00myscript
[root@localhost rc3.d]# cd ..
[root@localhost etc]# cd rc5.d/
[root@localhost rc5.d]# ln -s ../rc.myscript S00myscript
The S00 portion of the link is important. S stands for “on startup” (or more correctly, on runlevel change where this would start). The K stands for “on shutdown” (or more correctly, on runlevel change where it needs to be turned off). Don’t worry about creating a link for the K as this isn’t a init script with “start/stop” commands.
The number is two digits, and determines when it is run, in numerical order, staring from 00. For example, network on my system is S10network which means it starts pretty early in the boot process. Apache is S85httpd which means it starts pretty late in the boot process.
Have a look to see when things boot up, and number yours accordingly.
By cormander
Very similar to my Install FC9 into a chroot from a DVD iso article, I have created a new page on this site:
Quick CentOS5 Xen paravirt guest install
It’s a page because I’m going to keep it updated as much as possible with kernel versions and such so people can continue to copy/paste out of it.
Feedback is welcome, just send me an email.
By cormander
Here’s something for the weird scrapbook, an issue I had this morning with pygrub seeing an _old_ snapshot of the /boot partition of a Xen VM. On this VM I re-installed new kernel (from source), removed a few really old ones, and rebooted. After not coming back up for several minutes I got a console to it from the Xen host running CentOS5, and I got a kernel panic from the VM.
Looking at the output, it was trying to load modules from /lib/modules with unknown symbols, which typically happens when those modules weren’t compiled with the correct kernel symvers file. I had just manually installed the kernel, so I knew this wasn’t the case, but maybe I had copied them into the wrong directory? Puzzled, halted it and started it from the console with -c to see it as it booted up. I noticed that the number of kernels in the pygrub menu was 4, when there really were only 2 kernels in the menu.lst file.
So, I stop it there and mounted up the /boot partition from the virtual machine’s disk on the host. I looked at it, and as I expected, only two kernels in the menu.list file. Unmount and start again, and pygrub was still showing 4 kernels to choose from.
If I tried to boot a kernel that didn’t really exist, it would boot the vmlinuz and initrd file, but fail to load anything from /lib/modules on the root partition, because I uninstalled them. If I tried to boot the kernel I just reinstalled, it would panic on unknown symbols on boot. I had only one bootable kernel in the virtual machine (the second one, which still really existed).
Looking in the process tree of the host, I spotted a hdparm command that was ran on the device that this virtual machine is pointed to. I sent it a TERM signal and it didn’t die, so I started sending it KILL ( -9 ) signals. It still didn’t die. The only explanation that I could come up with is that it was a process that was hung waiting on a kernel thread.
It then suddenly hit me, even though I mount the /boot partition from the host and see what is really there, pygrub doesn’t do a mount. It actually does an open system call on the block device and reads data directly. This would put the contents of the /boot partition in filesystem cache. Now with the hdparm command open with that block device as a filehandle, and nothing else “writing” to the block device, I was guessing it would be held in the host kernel’s filesystem cache, so pygrub never actually touches the disk.
Not wanting to have to reboot, I tried clearing the filesystem cache by running these commands:
sync
echo 1> /proc/sys/vm/drop_caches
Then I ran the free command to confirm the filesystem cache was in-fact cleared. After it was, I started up pygrub again, BAM, it sees only two kernel entries, as it should.
I’ve never seen this happen before, but it sure was strange. This scenerio makes me want to see if I can backport the new pv-grub feature which is in the recently released Xen-3.3 to the CentOS5.2 version of xen.
By cormander
Well, since the NTFS kernel module is probably more sought after in an enterprise kernel more then the reiserfs module, I decided to also make an RPM for the nfts kernel module for the centos5 kernel. See the link below:
http://download.ravencore.com/misc/kernel-module-ntfs-2.6.18-92.1.10.el5.src.rpm
And, if I feel like it, I might start to maintain this stuff in a yum repo for i386 and x86_64. If that happens, I’ll even go ahead and throw a depmod command in a %post script of the RPM for you all so you can modprobe it, instead of having to insmod it.
