Ext4 is supposed to be much faster than ext3. Anything that makes development of EJBCA a bit quicker is interesting, so I just had to migrate to ext4 now that Ubuntu 9.04 is out.
The usual ext3 to ext4 migration guides are for normal unencrypted disk. Since my laptop has full disk enryption a few addition steps are needed.
Also the guides mention that you have to do 'grub-install' after migration. I did not have to do that.
Either it is because:
- I only migrated / and not /boot
- The standard upgrade to Ubuntu 9.04 already installed a new grub for me.
Anyhow, here are the steps hwo to migrate an encrypted root disk from ext3 to ext4.
Shut down computer properly, don't hibernate.
Boot from Ubuntu 9.04 cd and use it as a live cd (no changes to computer).
Open a terminal and become root.
#sudo su -
Set up crypto add encrypted disk to lvm
#cryptsetup luksOpen /dev/sda1 root
#lvm vgchange -a y
Mount root disk and just check that it's the correct disk before migrating
#mkdir /mnt/root
#mount /dev/tlap/root /mnt/root
Unmount and do the migration to ext4 (as described in the ext4 wiki and numerous other sites)
#umount /mnt/root/
#tune2fs -O extents,uninit_bg,dir_index /dev/tlap/root
#e2fsck -pfD /dev/tlap/root
Mount new ext4 disk and change fstab to ext4
#mount /dev/tlap/root /mnt/root
#cd /mnt/root/etc/
#vi fstab
Change ext3 to ext4 for you / disk (/dev/sda1 for me).
# /dev/mapper/tlap-root
UUID=ca86bf3d-40fb-4b4d-89c6-15ce94674fa0 / ext4 relatime,errors=remount-ro 0 1
Save, unmount /mnt/root and reboot.
After reboot check /etc/fstab and 'mount' and you will see that it's ext4 now.
tomas@tlap:~/tmp$ mount
/dev/mapper/tlap-root on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
...
Update:
I migrated my rather slowish home computer (AMD 4200+, 4GB, WD Raptor) running 'ant clean; ant' both before and after migration. The conclusion is that it takes 1 minute, give or take a few seconds, on both ext3 and ext4. Not huge leaps in speed there unfortunately.
Sunday, April 26, 2009
Thursday, April 23, 2009
What to do when you mac address of eth0 changed (debian/ubuntu)?
It always takes me too long to google up this answer so I'll write it here..
Either edit or delete this file:
/etc/udev/rules.d/70-persistent-net.rules
If you delete it, a reboot will create a new one with your new mac address.
Either edit or delete this file:
/etc/udev/rules.d/70-persistent-net.rules
If you delete it, a reboot will create a new one with your new mac address.
Tuesday, April 14, 2009
External RA improvements
In the upcoming EJBCA 3.9 the External RA is finally getting some long waited improvements.
The CA component will now run as a service in EJBCA. This means that you do most of the configuration in the admin-GUI of EJBCA and that it runs very nicely in a CA cluster. You can also configure multiple external RAs, as many as you need.
Setting up a cluster of external RAs is now very simple, if you have a cluster of two external RAs simply configure two external RA services in EJBCA and you're done. No need to use complicated database clusters etc on the external RAs, each external RA node can be simple and stand-alone.
Installation of the external RA is also much much simpler now. Configure the path to the external RA package in EJBCA and the needed CA service is automatically pulled into EJBCA so it is available to be configured in the Admin-GUI. The only thing that needs some though is the configuration of datasources in your application server.
To summarize:
- Easier to install and configure
- Runs nice in a CA cluster
- Runs nice against multiple external RAs
As an added bonus, it's also now almost trivial for developers to implement new types of external RA messages. Internally it uses java reflection, so all you have to do is implement the message classes and handlers. The rest is handled automatically.
The CA component will now run as a service in EJBCA. This means that you do most of the configuration in the admin-GUI of EJBCA and that it runs very nicely in a CA cluster. You can also configure multiple external RAs, as many as you need.
Setting up a cluster of external RAs is now very simple, if you have a cluster of two external RAs simply configure two external RA services in EJBCA and you're done. No need to use complicated database clusters etc on the external RAs, each external RA node can be simple and stand-alone.
Installation of the external RA is also much much simpler now. Configure the path to the external RA package in EJBCA and the needed CA service is automatically pulled into EJBCA so it is available to be configured in the Admin-GUI. The only thing that needs some though is the configuration of datasources in your application server.
To summarize:
- Easier to install and configure
- Runs nice in a CA cluster
- Runs nice against multiple external RAs
As an added bonus, it's also now almost trivial for developers to implement new types of external RA messages. Internally it uses java reflection, so all you have to do is implement the message classes and handlers. The rest is handled automatically.
Subscribe to:
Posts (Atom)