tech.kaotix.dk

Yesterday my MacBook Pro would no longer let me log into my bank account (as well as many other web sites). In Denmark a lot of web services utilizes a central login service called “NemID” (translates to EasyID). This login procedure uses a Java applet (don’t get me started on design choices!!). And it turns out to be not-so-EasyID, when your browser (or computer) no longer runs Java. And this was exactly what happened – I could no longer run Java. Apple simply – and without warning – decided that Java was too big a risk and that I didn’t need it any longer (don’t get me started on how much I loath Apple (and Java for that matter) right now!). Well guess what, Apple, I do need it!!

So I did some googling and found this solution somewhere:

First of all – This fix does leave your computer vulnerable to certain Java exploits. Do not go ahead with this if you do not know what you’re doing. And Please make a backup of the file you’re editing!!!

And now lets get to the nitty-gritty: Open /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist in your favorite text editor – you need to do this with superuser roots permissions e.g.:

a. Open Terminal (Cmd+Space to open “Spotlight”-> Type “terminal+enter” to launch)

b. To open the Xprotect.meta.plist into TextEdit as root, enter:

sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

You will be asked to enter your password – do as you’re told The File should now open in TextEdit.

c. change the following values:

<key>JavaWebComponentVersionMinimum</key>
<string>1.6.0_37-b06-435</string>

to

<key>JavaWebComponentVersionMinimum</key>
<string>1.6.0_37-b06-434</string>

and

<key>MinimumPlugInBundleVersion</key>
<string>1.7.11.22</string>

to

<key>MinimumPlugInBundleVersion</key>
<string>1.7.11.21</string>

and last but not least, change

<key>LastModification</key>
<string>Thu, 31 Jan 2013 16:55:59 GMT</string>

to some date in the future. This will prevent the XProtect.meta.plist file from being updated until the date specified.

d. Now save (archive) the file and restart your browser and Voila! – Java applets should be able to launch again (you may need to reactivate by clicking “Inactive Plug-In” though)

Hope this helps, It sure helped me.

On a RHEL5 server ulimit setting was not applied when I logged in using SSH. No matter what I did the setting remained the same. Doing a “su – ” to a user, however, worked like a treat. Strange! I did a bit of googling and found the following answer to my problem:

1. In /etc/pam.d/sshd add the line

session    required     pam_limits.so

2. In /etc/pam.d/login add the line

session    required     pam_limits.so

3. In /etc/ssh/sshd_config add

UsePAM yes

(this might already be in place in your config file – I’m not using a stock sshd_config)

4. reload SSH

/etc/init.d/sshd restart

Now change something in /etc/security/limits.conf

user1           soft    nofile  2048
user1           hard    nofile  4096

Log in as user1 – and voila!
ulimit -n should now show 2048 and ulimit -nH 4096

In our ESX environment, I extended a virtual disk from VirtualCenter and created a new partition on it using fdisk. The new partition was to be added to a Volume Group under LVM. But the OS (RHEL5 in this case) didn’t recognize the partition. “pvcreate” said it could not find the the device it was “Ignored by filtering” – As it turned out it was not so much a question of filtering as the fact that the device file was missing; /dev/sdb2 simply did not exist. I did a lot of searching and jumping through hoops for a solution that did not include a reboot (the server in question is a production server) – While there might very well be other solutions to this – the one I found turned out to be quite simple: Don’t use fdisk – use “parted” instead:

parted DEVICE
(parted) mkpart PART-TYPE START END
(parted) toggle PART-NUMBER FLAG

in my case it looked like this:

parted /dev/sdb
(parted) mkpart primary 53.7GB 107GB
(parted) toggle 2 lvm
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  53.7GB  53.7GB  primary               lvm
 2      53.7GB  107GB   53.7GB  primary               lvm

And Voila! – you’ll have a new partition AND the corresponding device file!

First of all. If you don’t know what a SMT-server is you probably don’t need to read any further.

Problem: I was deploying a number of SLES10-SP3 servers in an ESX environment by cloning from a running server – and that all went according to plan. However, when I tried to register the servers to our SMT server the first registration went fine, but the following registrations simply overwrote the previous.

Solution: Google to the rescue!! Rename “deviceid” and “secret” (you could choose to delete them instead if you’re that kind of sys admin – I’m not!) in /etc/zmd and re-run the registration process:

clientSetup4SMT.sh --host <your  SMT server>

On some of the servers I also had to run

suse_register -r

in order to restore the repository list, but on others I had no issues – well, go figure!

I noticed some strange behaviour on some SLES10-SP3 servers I was setting up in a .local domain. I could do a nslookup on the FQDN (<somehostname.local>), no problems there – but when trying to do a

ping <somehost>.local

it failed. I did a bit of searching on the internet and it turns out that SuSE (and as far as I could gather – other Linuxes as well) are haveing difficulties dealing with .local domains. The solution is to add the following to the end of /etc/host.conf

mdns off

And then do a reboot. Voila!

The following one-liner will generate a random eight character string consisting of numbers as well as upper- and  lowercase letters.

echo `< /dev/urandom tr -dc A-Za-z0-9 | head -c8`

or

tr -dc '0-9a-zA-Z' </dev/urandom |head -c8; echo

If you need a shorter or longer password you can ajust the “-c8”-value.

And yes, I know…… a password should contain special characters as well. Please feel free to add a few periods and asterisks

I found this on the net somewhere. I don’t remember where – sorry.

To add a vmdk to a virtaul RHEL5 server, you first of all need to create the vmdk (d’oh!) – I won’t go into that here. Next, on the RHEL5 server do as root:

echo "- - -" > /sys/class/scsi_host/host0/scan (the spaces between the dashed are important)

This will cause the scsi bus to be rescanned and the new disk should be found. For the devicename check “dmesg”. Now you can partition the disk, add it to LVM or whatever.

I needed to check the expiry date on a ssl certificate on a RHEL5 server (running a apache webserver).

In this case the location of the certificate was found in the ssl.conf file in the /etc/httpd/conf.d directory. It could very well be different in your setup, so you could grep for the string “SSLCertificateFile” in /etc/httpd/conf*

# grep -r "^SSLCertificateFile" /etc/httpd/conf*

and you should find the path to your certificate file (in my case /etc/pki/tls/certs/server.crt)

# cd /etc/pki/tls/certs (or the path you found above)
# openssl x509 -in server.crt -noout -enddate

Will tell you the expiry date.

I tried to do a shutdown of a VM from VirtualCenter (vSphere client)  only to recieve an error:  “another task is already in progress”.

Looking through my event-log in VirtualCenter, I saw that an earlier task (a cloning of same VM) had failed due to a timout.

The solution seems to be to log into the ESX servers service console and stop and start the mgmt-vmware service by doing:

# service mgmt-vmware stop

wait 30 seconds or so and start the service again

# service mgmt-vmware start

It seems that the wait is important. A mere “# service mgmg-vmware restart” did not resolve the issue.

This procedure will temporarily disconnect your esx-server – and VM’s running on it – from Virtual Center but otherwise it will not disturb your operation.

Recently a VM on a ESX host (version 2.5.3) refused to power on.

From the Service Console i tried to getstate:

vmware-cmd <.vmx-file> getstate

but all I got was an error:

/usr/bin/vmware-cmd: Could not connect to VM <.vmx-file>
  (VMControl error -14: Unexpected response from vmware-authd: Error connecting to /usr/lib/vmware/bin/vmware-vmx process.)

As it turned out the problem was that an old process was still existing and it was convinced it was running the VM already, which it was not.

# grep -r ".vmx" /proc/vmware/

extract the VM’s PID from the output and

# kill -9 <PID>

# vmware-cmd <.vmx-file> getstate

should now produce a more reasonable output. If you want to power on the VM da a:

# vmware-cmd <.vmx-file> start