We recently had a need to convert an organizations logo from a JPEG to a vector image.
The group had long ago lost the original of their logo and only had a single copy in JPEG format (dimensions 360x390, or the size of a posted note). Needless to say, when they asked if it could be used to print a large banner I had to laugh :-)
I ran across a couple of articles providing instructions using the freely available Inkscape.
Increase Image Resolution: Convert Raster Images to Vector
How to Convert a JPEG to a Vector Image
I found the first link to be the most helpful, but both were informative.
In the end, I was able to create a vector version of the logo that is, in theory, infinitely scalable. Pretty darn cool. Thanks Inkscape and eHow / Makeuseof.com
Friday, March 12, 2010
Tuesday, March 2, 2010
Build and Install Latest Grid Engine Roll for Rocks 5.3
This FAQ discusses the process of building the Sun Grid Engine roll for a Rocks 5.3 hpc cluster.
Why would you want to rebuild the roll? Possibilities include adding a later version of grid engine, or customizing the roll different from that provided by Rocks.
The latest version of Rocks at this time is 5.3 which includes Grid Engine 6.2u4.
The Grid Engine team released 6.2u5 in January. This version contains many new features and bug fixes over 6.2u4.
I built and tested this roll on a Rocks 5.3 x86_64 virtual machine prior to deploying it to the production cluster.
The overview:
Why would you want to rebuild the roll? Possibilities include adding a later version of grid engine, or customizing the roll different from that provided by Rocks.
The latest version of Rocks at this time is 5.3 which includes Grid Engine 6.2u4.
The Grid Engine team released 6.2u5 in January. This version contains many new features and bug fixes over 6.2u4.
I built and tested this roll on a Rocks 5.3 x86_64 virtual machine prior to deploying it to the production cluster.
The overview:
- Download the Rocks source code
- Download the Grid Engine source code
- Build the Roll
- Add the Roll to the head node
- Update the RPM on the head node
- Rebuild the compute nodes
Obtain the Rocks Source Code
- Download the Rocks source code tree (http://www.rocksclusters.org/roll-documentation/base/5.3/source-access.html) and make a backup of the original sge roll source in case you need to restore or compare files
- Create a new sge roll build area by copying the existing sge roll directory
- Download the Grid Engine source code (all versions of source are available at the Documents and Files page http://gridengine.sunsource.net/servlets/ProjectDocumentList ). Extract the source so we can later copy the installer script
$ mkdir -p ~/software/rocks-cluster
$ cd ~/software/rocks-cluster
$ hg clone http://fyp.rocksclusters.org/hg/rocks-5.3
destination directory: rocks-5.3
real URL is http://fyp.rocksclusters.org/hg/rocks-5.3/
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 2815 changes to 2815 files
2815 files updated, 0 files merged, 0 files removed, 0 files unresolved$ cd ~/software/rocks-cluster/rocks-5.3/src/roll
$ cp -a sge sge-v62u5$ mkdir -p ~/software/ge6.2u5-source
$ cd ~/software/ge6.2u5-source
$ wget http://gridengine.sunsource.net/files/documents/7/215/ge-V62u5_TAG-src.tar.gz
$ tar -zxf ge-V62u5_TAG-src.tar.gzBuild the SGE Roll
- cd to the sge roll directory and copy the 6.2u5 source code to the roll src directory
- Edit the roll version info
- Edit the SGE version info
- Create a new patch-files directory for V62u5 and copy the aimk SGE installer script and then edit as follows
- Edit the aimk install script as follows
- Edit the sge-client.xml file if you want to do any customizations to the clients, leave alone to accept the Rocks customizations
- Edit the sge-server.xml file to if you want to customize the head node settings (create custom parallel environments, etc...)
- Build the Roll (note you have to be ROOT to run this command)
$ cd ~/software/rocks-cluster/rocks-5.3/src/roll/sge-v62u5/
$ cp ~/software/ge6.2u5-source/ge-V62u5_TAG-src.tar.gz ~/software/rocks-cluster/rocks-5.3/src/roll/sge-v62u5/src/sge/vi ~/software/rocks-cluster/rocks-5.3/src/roll/sge-v62u5/version.mk
ROLLNAME = sge
RELEASE = 62u5
COLOR = plum
REDHAT.ROOT = $(PWD)vi ~/software/rocks-cluster/rocks-5.3/src/roll/sge-v62u5/src/sge/version.mk
NAME = sge
VERSION = V62u5
RELEASE = 1$ mkdir -p src/sge/patch-files/V62u5/gridengine/source
$ cp ~/software/ge6.2u5-source/gridengine/source/aimk src/sge/patch-files/V62u5/gridengine/source/$ vim src/sge/patch-files/V62u5/gridengine/source/aimk
set KRBLIB = "-lkrb5 -lz"# cd ~me/software/rocks-cluster/rocks-5.3/src/roll/sge-v62u5
# make roll > make-roll.log 2>&1Once this command completes, you should have a new ISO file in the build directory named "sge-5.2-62u5.x86_64.disk1.iso".
If you are installing a new Rocks 5.3 cluster, simply burn this ISO to CD and use it when selecting the SGE roll.
If you are upgrading your existing Rocks 5.3 cluster from 6.2u4 to 6.2u5, proceed to the next section.
Update GE on Existing Rocks 5.3 Cluster
Rocks 5.3 ships with GE62u4, following the procedure above we have built a roll to install GE62u5 to a new cluster. This roll can also be used to upgrade GE on an existing 5.3 cluster. I haven't tested or even thought about the idea of using this roll on a Rocks 5.2 cluster, so I really do not know if it would work.
The downside to this approach is that it doesn't allow you to install the newer version 'side by side' with the previous version. So I would recommend testing this on a virtual machine Rocks 5.3 cluster before doing so on the production cluster.
- copy the new roll to the head node if it isn't already there
- Add the roll using the rocks command. This will add the updated files from the roll that differ from the already installed sge roll
- Make sure that all running jobs have drained from the system before proceeding by first disabling the queues.
- Verify via qstat that running jobs have finished
- Stop the SGE services on the compute nodes, again be sure that the jobs have stopped otherwise this process will terminate them (repeat for other compute appliance types)
- Stop the SGE master process on the head node
- Backup your /opt/gridengine directory
- Run the roll to generate an install script. Under normal "Adding a roll" circumstances, you would procede by running the script, since we are upgrading an existing roll, it isn't necesary to do so. In fact, running the script may potentially overwrite some customizations that have been made to the grid engine since install time.
We will simply examine the script to find out what is necessary to perform the upgrade. - DON'T run the script!
- Examination of the script reveals that the only RPM that we really need to upgrade is sge-V62u5-1.x86_64.rpm, the rest of the script was already performed when we installed the head node (creation of parallel environments, sge user account, etc...)
- Use the loop below to update the rpms, again the only one that will actually update is sge-V62u5-1.x86_64.rpm, but just in case try them all
- Start the SGE master process on the head node
- Rebuild the compute nodes
- Once all of the compute nodes are rebuilt (and finished rebooting multiple times, i.e. OFED install, lustre, etc...) and you are ready to release the jobs, enable the queues
# rocks add roll sge-5.3-1.x86_64.disk1.iso
# cd /export/rocks/install
# rocks create distro$ qmod -d '*'$ sudo rocks run host compute command="/sbin/service sgeexecd.$(hostname -s) stop"
$ sudo rocks run host verari-compute command="/sbin/service sgeexecd.$(hostname -s) stop"$ sudo /sbin/service sgemaster.$(hostname -s) stop$ cd /opt
$ sudo tar -cjf gridengine-backup-62u4.tar.bz2 gridengine# rocks run roll sge > /tmp/install-sge-6.2u5.sh# for n in $(grep ^rpm /tmp/install-sge-6.2u5.sh |awk '{print $5}'); do echo $n; rpm -Uvh $n; done
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/db4-utils-4.3.29-10.el5.x86_64.rpm
Preparing... ########################################### [100%]
package db4-utils-4.3.29-10.el5.x86_64 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/javacc-4.0-3jpp.3.x86_64.rpm
Preparing... ########################################### [100%]
package javacc-4.0-3jpp.3.x86_64 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/junit-3.8.2-3jpp.1.x86_64.rpm
Preparing... ########################################### [100%]
package junit-3.8.2-3jpp.1.x86_64 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/libXp-devel-1.0.0-8.1.el5.x86_64.rpm
Preparing... ########################################### [100%]
package libXp-devel-1.0.0-8.1.el5.x86_64 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/openmotif-2.3.1-2.el5.i386.rpm
Preparing... ########################################### [100%]
package openmotif-2.3.1-2.el5.i386 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/openmotif-devel-2.3.1-2.el5.i386.rpm
Preparing... ########################################### [100%]
package openmotif-devel-2.3.1-2.el5.i386 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/pam-devel-0.99.6.2-6.el5.i386.rpm
Preparing... ########################################### [100%]
package pam-devel-0.99.6.2-6.el5.i386 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/rocks-command-sge-5.3-0.x86_64.rpm
Preparing... ########################################### [100%]
package rocks-command-sge-5.3-0.x86_64 is already installed
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/remove/host/plugin_sge.pyc from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/remove/host/plugin_sge.pyo from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/report/sge/__init__.pyc from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/report/sge/__init__.pyo from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/report/sge/machines/__init__.pyc from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
file /opt/rocks/lib/python2.4/site-packages/rocks/commands/report/sge/machines/__init__.pyo from install of rocks-command-sge-5.3-0.x86_64 conflicts with file from package rocks-command-sge-5.3-0.x86_64
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/rocks-sge-5.3-2.x86_64.rpm
Preparing... ########################################### [100%]
package rocks-sge-5.3-2.x86_64 is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/rocks-sge-5.3-2.x86_64.rpm
Preparing... ########################################### [100%]
package roll-sge-usersguide-5.3-0.x86_64 is already installed
file /var/www/html/roll-documentation/sge/5.3/index.html from install of roll-sge-usersguide-5.3-0.x86_64 conflicts with file from package roll-sge-usersguide-5.3-0.x86_64
file /var/www/html/roll-documentation/sge/5.3/rocks-copyright.html from install of roll-sge-usersguide-5.3-0.x86_64 conflicts with file from package roll-sge-usersguide-5.3-0.x86_64
file /var/www/html/roll-documentation/sge/5.3/roll-sge-usersguide.pdf from install of roll-sge-usersguide-5.3-0.x86_64 conflicts with file from package roll-sge-usersguide-5.3-0.x86_64
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/sge-V62u5-1.x86_64.rpm
Preparing... ########################################### [100%]
1:sge ########################################### [100%]
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/sge-drmaa-5.3-0.noarch.rpm
Preparing... ########################################### [100%]
package sge-drmaa-5.3-0.noarch is already installed
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/sge-ganglia-5.3-2.x86_64.rpm
Preparing... ########################################### [100%]
package sge-ganglia-5.3-2.x86_64 is already installed
file /opt/ganglia/lib64/ganglia/python_modules/sge.pyc from install of sge-ganglia-5.3-2.x86_64 conflicts with file from package sge-ganglia-5.3-2.x86_64
file /opt/ganglia/lib64/ganglia/python_modules/sge.pyo from install of sge-ganglia-5.3-2.x86_64 conflicts with file from package sge-ganglia-5.3-2.x86_64
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/sge-ganglia-5.3-2.x86_64.rpm
Preparing... ########################################### [100%]
package sge-ganglia-5.3-2.x86_64 is already installed
file /opt/ganglia/lib64/ganglia/python_modules/sge.pyc from install of sge-ganglia-5.3-2.x86_64 conflicts with file from package sge-ganglia-5.3-2.x86_64
file /opt/ganglia/lib64/ganglia/python_modules/sge.pyo from install of sge-ganglia-5.3-2.x86_64 conflicts with file from package sge-ganglia-5.3-2.x86_64
/export/rocks/install/rocks-dist/x86_64/RedHat/RPMS/sge-insert-ethers-5.3-0.x86_64.rpm
Preparing... ########################################### [100%]
package sge-insert-ethers-5.3-0.x86_64 is already installed
file /opt/rocks/var/plugins/insertethers/sge.pyc from install of sge-insert-ethers-5.3-0.x86_64 conflicts with file from package sge-insert-ethers-5.3-0.x86_64
file /opt/rocks/var/plugins/insertethers/sge.pyo from install of sge-insert-ethers-5.3-0.x86_64 conflicts with file from package sge-insert-ethers-5.3-0.x86_64$ sudo /sbin/service sgemaster.$(hostname -s) start# rocks run host compute '/boot/kickstart/cluster-kickstart'
# rocks run host verari-compute '/boot/kickstart/cluster-kickstart'$ qmod -e '*'Wednesday, February 3, 2010
Keep Grid Engine Configuration in Git
The SGE mailing list had an interesting post recently regarding keeping Grid Engine configuration under version control.
One of the respondents replied with their notes using Git:
http://olesenm.github.com/2009/11/05/gridengine-git-config/
Looks interesting, I'll update this post once I implement this on my Grid Engine master node.
One of the respondents replied with their notes using Git:
http://olesenm.github.com/2009/11/05/gridengine-git-config/
Looks interesting, I'll update this post once I implement this on my Grid Engine master node.
Monday, February 1, 2010
VMware Virtual Center Server failing to start at boot
I recently moved vCenter Server 4 from running on bare metal to a virtual machine. The vCenter Server is not starting successfully at bootup and the Windows Event Log has a message that doesn't provide much insight:
http://www.networknet.nl/apps/wp/archives/846
I believe that the issue is related to the timing of the services starting, in particular, the vCenter components are trying to start too soon before SQL Express is ready.
This VMware Forum posting may provide the workaround (creating a batch file to start the services):
http://communities.vmware.com/thread/208888
Event Type: ErrorI found one site that resolved this issue by manually copying SSL certs to "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL", however in my case, the directory and keys exist:
Event Source: VMware VirtualCenter Server
Event Category: None
Event ID: 1000
Date: 2/1/2010
Time: 9:38:03 AM
User: N/A
Computer: VCENTER
Description:
The description for Event ID ( 1000 ) in Source ( VMware VirtualCenter Server ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Error getting configuration info from the database.
http://www.networknet.nl/apps/wp/archives/846
I believe that the issue is related to the timing of the services starting, in particular, the vCenter components are trying to start too soon before SQL Express is ready.
This VMware Forum posting may provide the workaround (creating a batch file to start the services):
http://communities.vmware.com/thread/208888
- Create a new batch file called C:\Scripts\vc-start.bat (goofy that Windows doesn't provide a 'sleep' command)
sc config MSSQL$SQLEXP_VIM start= demand
net start MSSQL$SQLEXP_VIM
ping 127.0.0.1 -n 10 -w 1000 > nul
sc config vpxd start= demand
net start vpxd
ping 127.0.0.1 -n 10 -w 1000 > nul
sc config vctomcat start= demand
net start vctomcat - Set the following services to start manually in the "services.msc" MMC program
- SQL Server (SQLEXP_VIM)
- VMware VirtualCenter Server
- VMware VirtualCenter Management Webservices
- Test the new batch file from the command line
- Set the batch file to start on boot (procedure for Windows XP Pro and Win2k3)
- Open local computer policy: Start -> Run -> gpedit.msc
- Expand Computer Configuration\Windows Settings\Scripts
- In the right-hand pane, double-click Startup
- Click Add...
- Browse to C:\Scripts and double click vc-start.bat
- Leave script parameters empty
- Click OK and reboot
Friday, December 4, 2009
Expand that File System
The other day I received several 1 TB disks to add to an existing Dell MD1000. The user purchased the drives to expand a single file system on their RHEL4 server.
I figured I'd share the notes from the expansion in case they might prove useful to someone.
The existing layout:
Physically adding the disks can be done with the system online, just insert the caddies and allow a few minutes for the drives to be identified by the RAID controller.
Once the drives are installed restart Dell OpenManage (the server is a Dell, so we will use OpenManage to manage the RAID array) on the server so that it identifies the new hardware.
:1311/) and navigate to Storage -> PERC 6/E -> Virtual Disks
Select 'Reconfigure' from the drop down box next to the virtual disk that will be expanded. On the next screens, select all of the drives to add to the virtual disk and change the RAID level from 5 to 6. Once complete, the array will begin rebuilding. This will probably take several days to complete.
Once complete, I had to reboot the server before it would see the additional capacity.
Now for the Linux specific steps.
I figured I'd share the notes from the expansion in case they might prove useful to someone.
The existing layout:
- Server running RHEL4 x86_64
- MD1000 storage currently configured with several 1 TB drives allocated to a single virtual RAID 5 disk with a single hot spare
- The storage is treated as a block device (not partitioned via fdisk) as /dev/sdb
- The device is the sole member of a volume group and is entirely allocated to a single logical volume
- The lvm is formatted using ext3
- Physically add the new drives to the MD1000
- Assign the drives to the virtual disk and change the RAID from 5 to 6
- Resize the physical volume (pvresize)
- Extend the logical volume to use all of the additional extents (lvextend)
- Grow the file system to use the additional space
Physically adding the disks can be done with the system online, just insert the caddies and allow a few minutes for the drives to be identified by the RAID controller.
Once the drives are installed restart Dell OpenManage (the server is a Dell, so we will use OpenManage to manage the RAID array) on the server so that it identifies the new hardware.
Log into the OpenManage web page (https://
$ sudo srvadmin-services.sh restart
Select 'Reconfigure' from the drop down box next to the virtual disk that will be expanded. On the next screens, select all of the drives to add to the virtual disk and change the RAID level from 5 to 6. Once complete, the array will begin rebuilding. This will probably take several days to complete.
Once complete, I had to reboot the server before it would see the additional capacity.
Now for the Linux specific steps.
- The file system has to be unmounted. In my case, the partition is used to store user data and is not needed for the system to function. Thus it can be safely unmounted with the system in runlevel 3. If we were performing this on the root partition or other system partition, you'd need to boot to the rescue mode using the install media.
- Display the current size of the physical volume
- Resize the physical volume
- Running pvdisplay again will show the new free extents
- Now extend the logical volume by the number of free extents
- The lvdisplay command will confirm that that the logical volume is now expanded
- Running a file system check isn't such a back idea (this will take a long time to complete on a multi TB file system)
- Grow the file system (ext3)
- Mount it and let the users know they can begin to fill it up (that's their purpose in life, isn't it?)
# umount /data
# pvdisplay /dev/sdb | grep PE
PE Size (KByte) 4096
Total PE 1191679
Free PE 0
Allocated PE 1191679
# pvresize -v -d /dev/sdb
Using physical volume(s) on command line
Archiving volume group "vg_md1000" metadata (seqno 2).
Resizing physical volume /dev/sdb from 1191679 to 2860031 extents.
Resizing volume "/dev/sdb" to 23429381760 sectors.
Updating physical volume "/dev/sdb"
Creating volume group backup "/etc/lvm/backup/vg_md1000" (seqno 3).
Physical volume "/dev/sdb" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
# pvdisplay /dev/sdb |grep PE
PE Size (KByte) 4096
Total PE 2860031
Free PE 1668352
Allocated PE 1191679
# lvextend -l +1668352 /dev/vg_md1000/lv_data
Extending logical volume lv_data to 10.91 TB
Logical volume lv_data successfully resized
# lvdisplay /dev/vg_md1000/lv_data
--- Logical volume ---
LV Name /dev/vg_md1000/lv_data
VG Name vg_md1000
LV UUID xxxxxxxxxxxxxxxxxx
LV Write Access read/write
LV Status available
# open 1
LV Size 10.91 TB
Current LE 2860031
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0
# e2fsck -f /dev/vg_md1000/lv_data
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg_md1000/lv_data: 827839/610140160 files (2.4% non-contiguous), 1060122031/1220279296 blocks
# ext2online /dev/vg_md1000/lv_data
Tuesday, November 24, 2009
How To Encrypt Home on Fedora
Encrypt Your Linux Home Partition ¶
This how to explains the process of encrypting a partition on an existing system.
If you are installing a new Linux box, or reinstalling, the graphical installation for RHEL5.4 and later, Fedora, Ubuntu, OpenSuSE now all provide easy GUI tools to accomplish this.
Doing so on an existing system takes a bit of care so as not to destroy data.
The following are notes that I took while running through the process for the first time. Some steps may be redundant or unnecessary, if so, feel free to add comments and I'll adjust the process.
- Identify the partition that should be encrypted. In this example, I'm going to encrypt the partition (/dev/sdb1) that is mounted as /home
- Backup the data before proceeding. The process of encrypting requires a format, since this is /home, it makes sense to log out of the desktop, log in as root to the terminal (CTRL ALT F2) and 'init 3'. The /home directory can be safely unmounted
# init 3
# mkdir -p /backup/$(hostname -s)
# rsync -a /home /backup/$(hostname -s)
# umount /home - Use cryptsetup to initialize the LUKS partition (again, make sure it is umounted) and set the initial key / passphrase. Use whatever good passphrase you want to unlock this device in the future. If necessary, additional keys can be added for multi user support.
# cryptsetup luksFormat /dev/sdb1
- Identify the UUID of the partition
# blkid /dev/sdb1
/dev/sdb1: UUID="186f67df-9872-44d5-947c-a010d831f570" TYPE="crypto_LUKS" - Open the LUKS partition setting up a mapping named based on the UUID (this is the default naming convention used by the Fedora installer)
# cryptsetup luksOpen /dev/sdb1 luks-186f67df-9872-44d5-947c-a010d831f570
- Format the device, I'll use ext4 since it's the new standard on Fedora and Ubuntu
# mkfs.ext4 /dev/mapper/luks-186f67df-9872-44d5-947c-a010d831f570
- Once again, verify the UUID for the device, if you don't get this correct, the system will hang at bootup as it attempts to mount the device
# blkid /dev/sdb1
/dev/sdb1: UUID="186f67df-9872-44d5-947c-a010d831f570" TYPE="crypto_LUKS" - Add the device to crypttab to map it to the correct UUID
# vi /etc/crypttab
luks-186f67df-9872-44d5-947c-a010d831f570 UUID=186f67df-9872-44d5-947c-a010d831f570 none - Add the new mount to /etc/fstab so that it mounts at boot (make sure to comment or remove the existing /home entry). If you choose to automount encrypted partitions the boot process will pause prompting for the passphrase. This may be undesireable, especially in the case of a server where you might choose to mount manually following boot!
# vi /etc/fstab
/dev/mapper/luks-186f67df-9872-44d5-947c-a010d831f570 /home ext4 defaults 1 2 - Before you reboot, make sure to locate a copy of the installation media just in case you need to enter recovery mode (most likely due to a typo in fstab or crypttab)
# /sbin/shutdown -r now - During the boot process you'll be prompted to enter a passphrase to unlock the partition.
- If you need multiple keys (maybe this is a shared workstation or laptop), you can add new keys as follows
# cryptsetup luksAddKey /dev/sdb1
Chromium on Fedora 12
Update: Google now has an official repo for Linux that work for Fedora 12 and 13
20100917 - Updated the contents of this post to replace 'beta' package references to 'stable'.
Create the Google yum repository configuration file (replace x86_64 with i386 in the repo file to use the 32bit Google repository)
Then install Google Chrome
Original content:
Want to run Google Chrome web browser on your Fedora workstation? Not exactly Chrome, but you can install and run the open source browser (devoid of Google branding), Chromium, of which Google Chrome is based.
Chromium will install on both 32bit and 64bit systems.
First, create a new yum repository configuration file (/etc/yum.repos.d/chromium.repo):
v8 is Google's open source JavaScript engine.
20100917 - Updated the contents of this post to replace 'beta' package references to 'stable'.
Create the Google yum repository configuration file (replace x86_64 with i386 in the repo file to use the 32bit Google repository)
$ sudo vim /etc/yum.repos.d/google-chrome.repo [google] name=google - x86_64 baseurl=http://dl.google.com/linux/rpm/stable/x86_64 enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
Then install Google Chrome
$ sudo yum install google-chrome-stable ==================================================================================================================================== Package Arch Version Repository ==================================================================================================================================== Installing: google-chrome-stable x86_64 5.0.307.11-39572 google-chrome Installing for dependencies: cvs x86_64 1.11.23-8.fc12 fedora foomatic x86_64 4.0.3-8.fc12 updates foomatic-db noarch 4.0-8.20091126.fc12 updates gettext x86_64 0.17-16.fc12 updates libmodplug x86_64 1:0.8.7-2.fc12 fedora libmpcdec x86_64 1.2.6-6.fc12 fedora patch x86_64 2.6.1-1.fc12 updates pax x86_64 3.4-10.fc12 fedora phonon x86_64 4.3.80-5.fc12 updates phonon-backend-xine x86_64 4.3.80-5.fc12 updates qt x86_64 1:4.6.2-3.fc12 updates qt-sqlite x86_64 1:4.6.2-3.fc12 updates qt-x11 x86_64 1:4.6.2-3.fc12 updates qt3 x86_64 3.3.8b-28.fc12 fedora redhat-lsb x86_64 3.2-7.fc12 fedora xine-lib x86_64 1.1.16.3-5.fc12 updates
Original content:
Want to run Google Chrome web browser on your Fedora workstation? Not exactly Chrome, but you can install and run the open source browser (devoid of Google branding), Chromium, of which Google Chrome is based.
Chromium will install on both 32bit and 64bit systems.
First, create a new yum repository configuration file (/etc/yum.repos.d/chromium.repo):
[chromium] name=Chromium Test Packages baseurl=http://spot.fedorapeople.org/chromium/F$releasever/ enabled=1 gpgcheck=0Next install chromium, 2 packages will come from the chromium repo, chromium and v8:
$ sudo yum install chromium Dependencies Resolved ============================================================================== Package Arch Version Repository Size ============================================================================== Installing: chromium x86_64 4.0.252.0-0.1.20091119svn32498.fc12 chromium 9.7 M Installing for dependencies: minizip x86_64 1.2.3-23.fc12 fedora 24 k nss-mdns x86_64 0.10-8.fc12 fedora 21 k v8 x86_64 2.0.0-1.20091118svn3334.fc12 chromium 810 kOnce installed, you'll find Chromium on the Applications menu under Internet.
v8 is Google's open source JavaScript engine.
Subscribe to:
Posts (Atom)
