A Little Green Field

A few lucky people are naturally gifted when it comes to picking colors that work well together. The rest of us, well, we might need a bit of help from time to time.

Color Scheme Designer 3 is a nice free tool for that, just select the type of scheme you want (mono, complement, triad and so forth), pick a base color and the app will select appropriate colors and let you preview a page example (light and dark).

Apart from that basic functionality there are also a few more useful features, such as simulation of color blindness, selection of color space and export to a variety of formats. All packaged beautifully of course.

A note to begin with: Most of this is not specific for Proxmox VE, but rather general LVM stuff, but i my case I needed to do this with a Proxmox VE installation and that’s where the examples stem from. Hence the header.

The background: I’m setting up Proxmox VE (from now on I think I’ll just refer to it as Proxmox..) on an ordinary PC with two SATA disks. This is a consumer/smb, regular PC, so there’s obviously no hardware raid and Proxmox specifically states that they do not support software raid. I still want some redundancy, especially since the disks are ordinary consumer disks with a pretty high mileage. So I decided to set up LVM mirroring. I’ve never done that before, so this post is basically about me wanting to remember the stuff, but I guess it could be useful to others as well.

1. Start with a fresh Proxmox VE 2.0 installation. Log in via ssh. Run lvm.
2.  In my case I have two physical disks, one is used by Proxmox, the other is not in use:


   lvm> pvs
    PV VG Fmt Attr PSize PFree
    /dev/sda2 pve lvm2 a-- 148.55g 16.00g
    /dev/sdb lvm2 a-- 149.05g 149.05g

   (like I said, these are old disks which you might tell by the size. But 160 GB is enough for me.)

3. During installation Proxmox creates a volume group with three logical volumes:

   lvm> lvs
    LV VG Attr LSize Origin Snap% Move Log Copy% Convert
    data pve -wi-ao 91.30g
    root pve -wi-ao 37.25g
    swap pve -wi-ao 4.00g

4. I’ll add the unused disk to the volume group, it should be pretty self-explanatory:

   vgextend pve /dev/sdb

5. Depending on how full the first disk is there may be a need to free some space, preferably by downsizing the largest volume, which is empty at this stage.

   lvm> lvreduce -r -l 20%LV -v pve/data

   I’m selecting to reduce to 20% of the original size (-l 20%LV), this is pretty much arbitrary, I won’t need all that space, but I think that a smaller volume is also quicker to convert to the mirrored state.

   The -r means that the file system should be resized as well, the -v means verbose.

6.  Now I have about 90 GB free on my first disk, which should definitely be ok, time to mirror the first volume, but first some theory:This is done by using the command lvconvert, to convert the volume from an ordinary one to a mirrored. A mirrored volume needs a log which is used to keep the mirror volumes identical. That log could be placed on a separate device, on one of the devices in the mirror (obviously this defeats the purpose of mirroring), in memory or be mirrored itself.Since I only have two disks I can’t spare one to the log, there’s no meaning in putting it on one of the devices (what if that’s the one that dies?), so the choice is to either put it in memory or mirror it on the two devices I have.  Having it in the memory is a bit cumbersome, since that means it will be lost at every reboot, so the mirrors will have to be rebuilt at each reboot. This could be ok if it’s a server that’s seldom rebooted, but I prefer to mirror it on the devices.
7. However, I’ve not been able to create a mirrored volume with mirrored logs directly, so therefore I’ll start by creating a mirror with the log in memory:

   lvm> lvconvert -m1 --mirrorlog core -v pve/data

   The options are fairly straightforward, -m1 means “create one mirror”, –mirrorlog core means that the log should be kept in the memory, -v is still verbose.  Notice that I don’t tell lvconvert which devices to use, it will see that there are just two devices available and use those. The conversion could take really long time, so prepare to wait.

8. Now I’ll convert it again, stating that the logs should be mirrored on disk:

   lvconvert -m1 --mirrorlog mirrored -v pve/data

9. If I list the volumes now I’ll see that there are two data-images and two log-images, spread out over my two physical disks:

   lvm> lvs -a -o +devices
   LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices
   data pve mwi-ao 18.26g data_mlog 100.00 data_mimage_0(0),data_mimage_1(0)
   [data_mimage_0] pve iwi-ao 18.26g /dev/sda2(10560)
   [data_mimage_1] pve iwi-ao 18.26g /dev/sdb(0)
   [data_mlog] pve mwi-ao 4.00m 100.00 data_mlog_mimage_0(0),data_mlog_mimage_1(0)
   [data_mlog_mimage_0] pve iwi-ao 4.00m /dev/sda2(15234)
   [data_mlog_mimage_1] pve iwi-ao 4.00m /dev/sdb(4674)
   root pve -wi-ao 37.25g /dev/sda2(1024)
   swap pve -wi-ao 4.00g /dev/sda2(0)

10. That’s it, now I’ll just repeat step 6-8 with the other volumes. Then I’ll resize pve/data to whatever I need, making sure to leave some free space in the volume group, since Proxmox needs that for performing snapshotted backups.

All in all it’s a simple procedure, performed with standard tools.

One important thing to notice is that this means that the pve volume group will now extend over both disks. If I’m to reinstall Proxmox in the future I’ll need to make sure to remove both disks from the volume group, otherwise the Proxmox installation will by default only clear out the first disk and then there’ll be a conflict when setting up the volume group, since it already exists on disk no two. The installation will then abort with an error.

A little more than a year ago I worked a lot with Alfresco, mainly with Share. I liked it a lot, although it still missed a lot of functionality at the time, it seemed very promising for the future.

Then I started working with other things and more or less stopped following the development of Alfresco. But now I’ve had a reason to install it again, for a customer project and I must say that it has improved a lot in just one year.

One of the things I missed most in earlier versions was the ability to search in a meningful way. I mean, if you have a site full of content it’s not very useful to be able to search for keywords only and get every single item that matches the keywords in any way at all. But nowadays a more powerful advanced search has been introduced and at a first glance it looks really useful.

I also like the fact that it’s possible to create content directly in the document library. Since that’s basically the same functionality as the Wiki it seems a bit odd that it hasn’t been included before, but still, it’s nice to see that it’s there now.

(Speaking of the Wiki, I really don’t see the need for that as it is today. Sure, you can link between pages, but other than that there’s really not much of a difference between creating a wiki page and a document. I’d like to see a proper wiki implementation, more like MediaWiki.)

Besides that, there are many more new or extended features that I look forward to test out (workflows etc), but the one thing that caught my interest the most is the new replication functionality. Not so much for the possibility to replicate between production sites, but for the fact that it might be a nice backup and disaster recovery tool.

Previously I’ve always found that hot backups were a pain in the *** with Alfresco. Ok, you could backup files with CIFS, but then you’d lose all meta data and what about the rest of the stuff? Backing up the repository could be done, but without exact timing of database backup and file backup there’s a big risk to end up with an inconsistency that might break the entire repository.

I haven’t really looked in to the new replication feature, so I don’t know to what extent it could be useful for backup purposes, but it sure seems interesting at first glance.

When using LDAP authentication with vTiger, sometimes you want some users to authenticate against the database instead. One example is the admin user, which by default works that way, but there may be other cases as well.

To allow for that you may populate an array in the LDAP config file (config.ldap.php) with users that should be authenticated against the database. It could look like this:

$AUTHCFG['sql_accounts']         = array("user1","admin");

This config means that users admin and user1 will authenticate with whatever password is stored in the SQL database.

The problem comes if user1 wishes to change his or her password in vTiger. If the system is set up for LDAP authentication no users, except for admin, which is an exception, will be able to change their passwords on their profile pages. The password field will only say LDAP Authentication, instead of showing a Change Password-button.

The reason for this is that the code creating the profile page checks which type of authentication that is used as standard, not which type that is used for this particular user.

To fix this you need to edit the file that contains the code creating the profile page: modules/Users/DetailView.php

Locate this section:

        global $AUTHCFG;
        $auth_type = strtoupper($AUTHCFG['authType']);

        // Allow to change the password of the local predefined 'admin' account
        if ($focus->user_name == 'admin') $auth_type = 'SQL';

        switch ($auth_type)
        {
        case 'AD':
                $buttons = "Active Directory authentification";
                break;
        case 'LDAP':
                $buttons = "LDAP authentification";
                break;
        default:
                $buttons = "";
                break;
        }

Comment out this line:

if ($focus->user_name == 'admin') $auth_type = 'SQL';

And instead add something like this:

// A bit of code to see wether the user authenticates through SQL
if (in_array($focus->user_name, $AUTHCFG['sql_accounts'])) $auth_type = 'SQL';

That should fix the problem!

Operakällaren satsar just nu på att lansera sitt sortiment av matlådor, under namnet Gooh!, runt om i landet. Jag har tidigare sett att de har funnits att köpa på t.ex. Centralstationen i Stockholm, men nu är tydligen tanken att lunchätare runt om i Sverige som är trötta på sorgliga ursäkter till frysta matlådor ska få chansen att äta lite riktig mat istället.

I samband med det här så söker man just nu testpiloter via Smartson, 1 000 personer ska få chansen att tycka till om maten. Perfekt för någon som mig, som tyvärr äter alldeles för mycket dåliga luncher på jobbet!

Tja, varför inte? Ärligt talat, grädde är ju gott, inte minst till diverse efterrätter, men nog vore det trevligt med lite variation? Kanske chokladgrädde till marängswiss, eller ännu hellre: jordgubbsgrädde till våfflor (så kan man skippa sylten också).

Ett litet frågetecken är att grädden bara innehåller 27% fett, men enligt Arla så ska den gå utmärkt att vispa ändå och i så fall är det ju faktiskt ingen nackdel att den är lite magrare än vanlig vispgrädde.

Hursomhelst, Smartson ger just nu chansen att prova grädden och blogga om den, så med lite tur får jag anledning att återkomma till den inom en snar framtid.

Apple likes to take things and do them their own way. Sometimes that’s good, sometimes not so good.

One particularly annoying example is the fact that Apple for some reason thinks it’s important to send along file metadata when creating archives designated for file systems that cannot handle this metadata. Or in plain English: Whenever you create a tar archive in OS X, it will be full of hidden files, beginning with a dot, that contains metadata about the files in the tar archive. This might be good if you unpack the files in OS X, where the metadata could automatically be restored with the files. But if you, which is very likely if you use tar in the first place, intend to unpack the archive in another unix-ish environment you will have no use of the dot files, they will only be an annoyance.

Fortunately this could all be avoided, by telling OS X that you have no interest in the metadata. This could be done by simply setting an environmental variable. To do this, issue this command in a Terminal window:

export COPYFILE_DISABLE=true