Was getting this error on our puppetmaster that only had a few clients. Turns out it's just an error from mysql being passed down the line. We share our mysql for puppet with multiple servers. Restarting mysql saved the day... Read http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html for instructions on increasing the limit...

mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 100 | +-----------------+-------+ 1 row in set (0.00 sec) mysql>

increasing the limit in /etc/my.cnf

[mysqld] datadir=/var/lib/mysql ... max_connections=200 mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 200 | +-----------------+-------+ 1 row in set (0.00 sec) mysql>

We had a machine that would keep coming up with devXXXXX where XXXXX is a seemingly random number. We tried ifrename to no avail, modprobe -r didn't help, modules.conf didn't help. It turned out that the HWADDR line in the ifcfg-ethX file was wrong. After fixing the line we were able to do ifup ethX and the devXXXXX went away.

This is my first android phone, so I thought I'd share my experience of rooting the phone. All credit to Zinx Verituse over on Alldroid.org

Note: I just updated to the update released December 10th for the droid and was able to reapply the update.zip.

The instructions are here

• Download this file and rename it update.zip on the sdcard.
• turn off the phone
• turn on the phone holding down the x key on the keyboard
• When you see the Motorola symbol, press Vol+ and Camera buttons together.
• An onscreen menu will appear, use the d-pad to navigate to update.zip and type return to apply
• After the phone reboots, Go to Settings -> Applications -> Development and enable USB Debugging
• Connect the droid to your desktop, download the sdk
• unpack the sdk and navigate to tools directory
• as root/administrator run adb start-server
• next run adb shell
• su to root /system/bin/su
• remount the root filesystem rw

  # mount rootfs / rootfs ro 0 0 tmpfs /dev tmpfs rw,mode=755 0 0 devpts /dev/pts devpts rw,mode=600 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0 none /dev/cpuctl cgroup rw,cpu 0 0 /dev/block/mtdblock4 /system yaffs2 ro 0 0 /dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev 0 0 /dev/block/mtdblock5 /cache yaffs2 rw,nosuid,nodev 0 0 /dev/block/mtdblock0 /config yaffs2 ro 0 0 /dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 # mount -o remount -o rw -t yaffs2 /dev/block/mtdblock4 /system

  I don't know if the device will always be the same (/dev/block/mtdblock4), best to check first.
• now make a copy of sh and call it su-something or replace su

  # cd /system/bin # cat sh > su or # cat sh >su-fake # chmod 4775 su or # chmod 4775 su-fake # exit

You now have either su or su-fake that you can run from terminal emulator on the phone and become root. To start using your new privileges, install busybox and symlink to it for all the tools that are missing...

After upgrading to 0.25, the following error occurs:

Could not retrieve catalog from remote server: Could not intern from pson: Could not convert from pson: Could not find relationship target ''

This turned out to be because of recipes using exec without naming the exec. Example

exec { "cat /that/file": unless => "something", path => "/bin", refreshonly => false }

should be rewritten as

exec { "cat that file": command => "cat /that/file", unless => "something", path => "/bin", refreshonly => false }

The error goes away after making the change and all is well.

I don't really see the benefit of using adsense anymore. Everyone knows they're ads, no one clicks. It doesn't pay my isp bills anymore, so I'm dropping it. They were only annoying anyway.

The problem I was trying to fix here was that I had a package that required a much newer version of a library than the system had installed on it. I didn't want to ruin the stability of the system by updating the library so I build it and placed it in a non standard location (harkening back to the solaris days I guess). If you can't guess what the problem was, I called the library package qt4-vlc...hint hint.

That part went fine, but whenever I tried to build my package that was supposed to use qt4-vlc, it would use the system libs in %{_libdir}/qt4...I tried to use rpath as a solution but couldn't get the syntax right. I looked at the gnu documentation but that didn't work because gcc kept complaining that it didn't know what the -rpath option meant.

The solution was to escape all the -rpath options that are for the linker (ld) and not gcc. Using -Wl, passes arguments to the linker and ignores them in the compiler. The final line I arrived at is:

LDFLAGS='-Wl,-rpath -Wl,%{_libdir}/qt4-vlc' $LDFLAGS export LDFLAGS

I put this in the %build and the %install stages. In %build I put it before %configure and in %install it's before %makeinstall. How to read this is that the -Wl, just says, pass the next argument to ld, so

-Wl,-rpath -Wl,%{_libdir}/qt4-vlc

is sent to the linker as

-rpath %{_libdir}/qt4-vlc

Once I figured that out, it was all good. But it seems a bit silly to have two of the -Wl, clauses, since you can just put in another comma. In the end I just used this:

-Wl,-rpath,%{_libdir}/qt4-vlc

It's not only more compact, it's easier to read..

I posted some additional material on building rpms in the appendix of the book. I cover how to build an example spec file from scratch. This is similar to what I did in my presentation, just with a lot more detail. I hope to expand this section to cover nested packages and kernel modules. Those sections are not done yet...read it here.

I'm still working with my own kvm implementation even though RedHat has released their own in RHEL 5.4, they are, however, at version 83, I'm on 88. I'd rather stay current since kvm is moving so fast that each new version fixes bugs and adds many new features.

I ran into a problem when applying the new selinux policy from RH, they have added support for qemu/kvm to the policy, which is great but blows up on my fibre channel disks. I tried to create an selinux module to fix the problem but kept getting this:

[root@hypervisor kvm]# semodule -i kvmmultipath.pp libsepol.check_assertion_helper: assertion on line 0 violated by allow qemu_t fixed_disk_device_t:blk_file { write }; libsepol.check_assertion_helper: assertion on line 0 violated by allow qemu_t fixed_disk_device_t:blk_file { read }; libsepol.check_assertions: 2 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed!

My te file looked like this:

module kvmmultipath 1.0; require { type fixed_disk_device_t; type qemu_t; class file { read write getattr }; class blk_file { read write getattr }; } #============= qemu_t ============== allow qemu_t fixed_disk_device_t:blk_file { read write getattr };

The problem here is that blk_file isn't just a simple class, it relies on file. I tried including file, but that didn't work either. The solution was to read the manual :-( and use the devel package. I installed selinux-policy-devel and looked at the include files, the one of interest here is /usr/share/selinux/devel/include/kernel/storage.if which defines a interfaces called storage_raw_read_fixed_disk and storage_raw_write_fixed_disk. Using these interfaces instead of the allow statement fixed the problem. To use these interfaces, I had to change the policy definition to use the macro policy_module also. I then used the Makefile in devel to make the module.

policy_module(kvmmultipath, 1.0); require { type fixed_disk_device_t; type qemu_t; class file { read write getattr }; class blk_file { read write getattr }; } #============= qemu_t ============== storage_raw_read_fixed_disk(qemu_t); storage_raw_write_fixed_disk(qemu_t);

To build the module:

[root@hypervisor kvm]# pwd /usr/share/selinux/devel/kvm [root@hypervisor kvm]# ls kvmmultipath.te [root@hypervisor kvm]# make -f ../Makefile Compiling targeted kvmmultipath module /usr/bin/checkmodule: loading policy configuration from tmp/kvmmultipath.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 6) to tmp/kvmmultipath.mod Creating targeted kvmmultipath.pp policy package rm tmp/kvmmultipath.mod.fc tmp/kvmmultipath.mod [root@hypervisor kvm]# semodule -i kvmmultipath.pp

Yay, kvm's can access the fibre channel again..now to upgrade the rest of the hypervisors.

I have a server that many people are mistaking for my login (ssh) machine, so I decided to forward attempts to ssh into this machine to my real login machine. I found a few posts on this but they were all somewhat incomplete for my purposes There are two problems here, you need to enable ip_forward in the kernel, and then you need to write a nat table for iptables. I'm going to assume you don't have a nat table to begin with.

Step 1, enable ip_forward.

[root@notlogin ~]# sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1 [root@notlogin ~]# echo net.ipv4.ip_forward=1 >>/etc/sysctl.conf

Step 2, create a nat table, you can do this command line (go commando) or edit /etc/sysconfig/iptables, your call.

*nat :PREROUTING ACCEPT [13:1035] :POSTROUTING ACCEPT [5:516] :OUTPUT ACCEPT [12:966] -A PREROUTING -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.0.10:22 -A POSTROUTING -j MASQUERADE COMMIT

If you do this, you won't be able to get into your box via ssh anymore though, you should add an exception for yourself so you can still get into the box via ssh. In the example, the ipaddress of this host is 192.168.0.1 and my client (me) is 192.168.0.2

*nat :PREROUTING ACCEPT [13:1035] :POSTROUTING ACCEPT [5:516] :OUTPUT ACCEPT [12:966] -A PREROUTING -s 192.168.0.2 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.0.1:22 -A PREROUTING -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.0.10:22 -A POSTROUTING -j MASQUERADE COMMIT

What we're saying here is that if I'm coming from 192.168.0.2, just pass me into the real machine (192.168.0.1), if I'm not, do the next rule and pass me off to 192.168.0.10. The fun thing is that you can change the port too, so you could have people trying to telnet to port 23 on 192.168.0.1 be redirected to ssh on 192.168.0.10 also.

Hope that saves someone some time.

Here is a talk I gave on creating/building rpms. It covers spec files and some basics of how an rpm is organized. Hopefully it's useful to someone. This includes a tutorial on how to make a spec. I plan of having a more detailed tutorial in the appendix to mybook, I'll post that here when I finish it. rpm-talk