Archive
You are currently browsing the archives for the packages category.
By cormander
The other night I took the time to sit down and go through all the options in the linux kernel configuration menu. I then proceeded to remove everything that would be unrelated in a xen domU environment to create a small and optimized kernel to run virtual servers for. For anyone interested, this is what I came up with.
For now I’m only going to put this slimmed down configuration on the stable kernels in my repository (linux 2.6.32.9 currently) because I really don’t have the time to do this and test it for every single new major kernel release. But this configuration makes a really small kernel image; only 2.9 MB and it boots a little faster then the previous kernel image inside xen in which I was using the “defconfig” options.
I basically stripped out all hardware support and got right down to what virtual systems need. It isn’t built with module support and has the most commonly used filesystems (including network filesystems) built right into the kernel. I almost went as far as to do an “embedded” configuration but then you lose stuff like virtual frame buffer support and xen console support, which I do want to keep. But so far so good with it.
If I have some time to run some benchmarks on it vs. the previous “defconfig” image, I’ll post the results here on my blog.
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
The other day I went ahead and uploaded some new packages for gradm and paxctl. You can download this to your /etc/yum.repos.d/ directory:
http://rpm.cormander.com/repo/grsec/rouge-beret-grsec.repo
And then:
yum install gradm paxctl
This is a new version of gradm with the “grsecurity” dependency removed. No reason why you can’t install it on a non-grsec host, the command just won’t work. The version of paxctl is the same (no updates in a while), but has an upgraded paxtest, and the “pax-linux” dependency was removed.
Sometime soon I’ll create a rouge-beret-repo RPM package that has the yum .repo files for these repositories.
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
The following is a non-elegant, non-standard, don’t-ever-do-this-unless-you-know-what-you-are-doing way of creating an RPM based off of what you have installed on your system. If I get some time later I’ll create a more “proper” script and update this article with a link to it.
Say you have kernel-xen-2.6.18-92.el5 installed on your system, but don’t have the RPM for it. Say all centos mirror servers simultaneously combusted; poof, gone. Say you wanted to roll out the kernel to other nodes, but wanted to do it with RPM. Here is how you’d create a hack-n-slash RPM file with all the files from the RPM:
Create this file: /tmp/filelist
/lib/modules/2.6.18-92.el5
/boot/config-2.6.18-92.el5
/boot/initrd-2.6.18-92.el5.img
/boot/symvers-2.6.18-92.el5.gz
/boot/System.map-2.6.18-92.el5
/boot/vmlinuz-2.6.18-92.el5
The above is a list of files and directories you want to copy into the RPM. With the following script, if you list a directory, do not list any subdirs. I haven’t even bothered testing that yet. I’ll refine that if I ever take another, more in-depth whack at this.
Create this script: mkRPMfromBinaries.sh
(be sure to edit the name/version/release values with what you want your package to be)
#!/bin/bash
name=kernel-xen
version=2.6.18
release=92
filelist=/tmp/filelist
if [ ! -f $filelist ]; then
echo "Please create a list of files to make the RPM from in: $filelist"
exit 1
fi
cat << EOF > /tmp/$name.spec
Name: $name
Version: $version
Release: $release%{?dist}
Summary: CHANGEME
Group: System Environment/Base
License: CHANGEME
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
AutoReq: on
%description
CHANGEME
%prep
%build
%install
rm -rf \$RPM_BUILD_ROOT
for i in \$(cat $filelist); do
mkdir -p \`dirname \$RPM_BUILD_ROOT/\$i\`
cp -a \$i \$RPM_BUILD_ROOT/\$i
done
%clean
rm -rf \$RPM_BUILD_ROOT
%files -f $filelist
%defattr(-,root,root,-)
%changelog
EOF
rpmbuild -bb /tmp/$name.spec
Make it executable, and run it (as root). Assuming you have the 2.6.18-92.el5 kernel-xen package installed, it’ll create a RPM for you.
Note that the RPM it generates doesn’t have the pre or post scripts, and is nothing more than a container for all the files you specified. It’s a very hackish way to create an RPM. Don’t ever do this. Not ever! I’m serious! And since you’re doing it anyway, don’t come crying to me if you get unintended results.
Have a great day.
By cormander
Since I’m planning on doing a new version of rootsh sometime in the near future, I decided to piece together as much revision history of the program as I can. I published the git repo here:
http://github.com/cormander/rootsh
Most of it is imported from CVS on sourceforge. The revision history wasn’t complete and was a complete mess, I had to do some creative hackery to get it all put together. I preserved the author, and kept timestamps as accurate as possible. The tagging was a little difficult as there were few points in CVS that actually looked like the releases, so a few of the commits are manufactured by me to make the version tagging actually accurate to what the release tarballs look like.
I released version 1.5.3 about a year ago, which is why I’m in there as well. I had a few patches I wrote for the program and that’s when I took over maintenance of the project, but those weren’t in a version control system either so I didn’t bother to try to separate them out and assign commit dates and times to them.
Current plan is to make version 2.0 which logs to sqlite instead of flat files. This is so input and output are caught and logged with accuracy in time, and a replay tool that can actually accurately show things as they actually happened in time (with pause, fast-forward/backward, and slow/fast motion). This will be important as it’ll allow far easier examination of sessions, particularly when the user was in an editor.
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 decided to start to use github:
http://github.com/cormander
Currently two projects pushed there; a ravencore repo that other people should be able to commit to without me having to do anything, and a cpan2rpm repo I just whipped together with some patches added that I’ve been using for some time.
These repos are both mirrored on my site at http://git.cormander.com/.
By cormander
The past week I’ve been talking about Hudson, and not just here. Quite frankly I think some of my buddies are sick of me talking about it. For this (and other) reasons, I exposed the build system at this URL:
http://build.cormander.com/
I granted anonymous view access to most of it. I currently have ravencore in there, and my grsecurity stack setup in there and building successfully. Pretty soon I’ll be putting rootsh and other projects I manage in there, as well as things like python26 for CentOS, Xen 3.4 for CentOS, and any other thing that comes to mind that I have built and made use of.
And as far as this saving my world goes, it’s because it reduces the amount of effort I have to put into this stuff, which means I can do more of it.
