Yum doesn’t have a reinstall feature, and I didn’t want to do a remove first, the packages were currently in use. So how to do a reinstall?

Remove the package from the RPM database without actually removing it:
# rpm -e --justdb --nodeps "package name"

The package is still installed but when yum queries the RPM DB it will find it missing and allow you to install it:
# yum install "package name"

This would have come in really handy last week. I upgraded an out of date file server and the latest samba broke Directory authentication, which was not cool and file shares cold not be authenticated until the problem was solved. CentOS do not keep old packages in their repos. I had to compile a FC6 version of samba to rollback to a working state until I investigated and found a patch.

The bug is dated May, the patch has been out for months, and the fix is still not in official repos.

Anyway back to rollbacks, 2 steps:

1. In /etc/yum.conf add the line: 
   tsflags=repackage
2. In /etc/rpm/macos (create it if it does not exist), add the line:
   %_repackage_all_erasures 1

Now if the update or install clobbers something, you can roll back packages to their former state just with a simple rpm command.

Examples:

rpm -Uhv –rollback ‘9:00 am’,
rpm -Uhv –rollback ‘4 hours ago’,
rpm -Uhv –rollback ‘december 25′.

Follow the instructions from the previous post, modify them to say nfs4 instead of fuse.

Update: 13/11/2008

Patch file you can apply to the SRPM of gnome-vfs: gnome-vfs-2162-nfs4-trash.patch

Kerberos authentication requires the time to synced before it will work. Redhat (CentOS) tries mounting Network filesystems before syncing the time on startup. Can anyone else see the problem?

If any of our lab machines have their time out by more than 5 minutes the mount will fail.

I have changed the startup priority of ntpd from 58 to 12, and this has fixed the problem.

As ntpd only requires networking to work, I cannot understand why it starts at 58, but problem solved.

For a couple of years now Xdmx has been rolled into the Xorg source and getting it configured is really not that hard. When I have ironed out this install I may write a howto. But while some stuff was working just fine and dandy most apps that use a modern widget library for the UI (ala GTK or QT) were failing to render fonts properly, not drawing icons, messing up colors and just not looking right in general.

I scoured the interweb for answers, and the main thing I saw was just forum posts instructing users to turn of the Xorg render extension. This works, though makes the rendering of windows very, very slow. On what should be a high performance render wall I have an issue with this.

Anyway, I eventually found this post, and figured it was worth a try. And it Worked! brilliant! QT, GTK, Firefox, everything is looking peachy.

I threw it together in this patch file which I applied to the SRPM for xorg-x11-server.

Pretty simple to fix, a bit lazy, but it will only take you 5 minutes.

Grab the rpm sources for libHX and pam_mount from your local Fedora 9 mirror. I got mine from here:

http://mirror.aarnet.edu.au/pub/fedora/linux/updates/9/SRPMS/pam_mount-0.41-2.fc9.src.rpm
http://mirror.aarnet.edu.au/pub/fedora/linux/updates/9/SRPMS/libHX-1.18-1.fc9.src.rpm

Build the libHX source:

# rpmbuild --rebuild libHX-1.18-1.fc9.src.rpm

Install the libHX rpm and the libHX-devel rpm. Now build pam_mount the same way:

# rpmbuild --rebuild pam_mount-0.41-2.fc9.src.rpm

Use “yum localinstall” to install pam_mount as it probably needs to grab a perl XML module as well.

But if you try and connect to an up to date Xvnc server it will probably fail, you need to specify that your VNC server uses the VNC protocol 3.3 for backwards compatibility, the command option is simply “-Protocol3.3″ you will now be able to connect to your Xvnc server from Leopard using the built in viewer.

If you were to follow my earlier instruction for a GDM VNC Server then simply add this option to: /etc/xinetd.d/vnc

UPDATE #1

You will notice that the connecting to server box doesn’t go away, this is because Apple does not like the option: -securitytypes=none

Setup a password file using vncpasswd and remove the above option and add the option:

-rfbauth=/path/to/vncpasswd_file

I am sure there is a better way to do this, but I am working on a linux lab build and the PC speaker beep is annoying me. Really annoying me.

I can only imagine what a lab full of beeping PCs would be like. The quickest way to stop the beeps I found was to unload the pc speaker driver:

modprobe -r pcspkr

If you want to turn it off permanently add a line /etc/modprobe.conf

alias pcspkr off ]]> http://blog.sumostyle.net/robg/2008/07/24/annoying-pc-speaker-beeps/feed/ 0 http://blog.sumostyle.net/robg/2006/11/15/gdm-logins-using-vnc/ http://blog.sumostyle.net/robg/2006/11/15/gdm-logins-using-vnc/#comments Wed, 15 Nov 2006 00:00:00 +0000 robg http://blog.sumostyle.net/robg/?p=82 It is possible to allow remote users to login to gnome, using gdm as you would on console, via vnc. There are other tools to do this, like NX, which are technically superior, but vnc clients are almost ubiquitous making this solution work for almost any client.

We will use xinetd to handle the incoming connections. Since Core 4, xinetd is not installed by default, I have tested this on FC3 – FC6. We also need the vnc-server software as well. To install the required software:

# yum install xinetd vnc-server

Open the GDM configuration tool: System -> Administration -> Login Screen. Select the ‘Remote’ tab. Style will currently read “Remote login disabled”. Change this to read “Same as local”.

It is probably a good idea to disable remote system logins under the security tab, unless you need it.

All of these gdm settings can be edited directly as well, /etc/X11/gdm/gdm.conf in FC3 and FC4, /etc/gdm/custom.conf for newer versions.

The relevant gdm|custom.conf entries:

[daemon]
RemoteGreeter=/usr/libexec/gdmgreeter

[security]
AllowRemoteRoot=false

[xdmcp]
Enable=true

Make sure vnc is not launching on startup:

# chkconfig vncserver off

Edit /etc/services, adding a new service at the end of the file:

# Local services
vnc             5900/tcp                        # vncserver

Now we need to define the new service. Create the file /etc/xinetd.d/vnc.

service vnc
{
     disable = no
     socket-type = stream
     protocol = tcp
     group = tty
     wait = no
     user = nobody
     server = /usr/bin/Xvnc
     server_args = -inetd -query localhost -geometry 1024x768 -depth 16 -once -fp unix/:7100 -securitytypes=none
}

Save the file. To see the changes, you can restart the machine, or:

# gdm-restart (This will kill X Windows)
# service xinetd restart

From your machine you will now be able to run ‘vncviewer localhost:0′, and if everything has worked, a vnc window should appear and show a login screen.

Firewall and Security Issues

You will probably find however, that if you try this from another machine it won’t work, your firewall will be stopping the connection. One solution is to open up port 5900 on the firewall, however, vnc sends information over the network un-encrypted, including any passwords you might type in. The better solution is to leave your firewall blocking vnc and tunnel the connection over ssh.

On the client machine (not the vnc server the machine you are connecting from), make an ssh connection to the host machine (the vnc server):

$ ssh -L 5901:localhost:5900 vnc.host.machine

This will attach your local port 5901 to the remote machine’s port 5900, the port that runs VNC. You can now attach your vncviewer to your local port, and ssh will tunnel it through to the remote machine.

$ vncviewer localhost:1

You should now have secure remote logins to your machines.