For example, the iPhone has limited vibration functions.  Compared to a Blackberry in this regard, where the typical IT professional needs to be discrete in meetings but still needs to know the difference between an email (one vibration), a blackberry message (two quick vibrations), or an SMS message (three quick vibrations) in order to judge the urgency.  The iPhone just does a short vibrate.. once.

With that aside, the phone is still amazing.  Fix the alert options, and it could be a real contender in the office environment.

SMS message conversations blow the doors off of any other phone.  But how does one back these up? Low-and-behold, iTunes syncs these up behind the scenes, but it doesn’t provide an interface to them. Say you want to preserve them, but don’t want them piling up on the phone.

A small script in perl on a linux box will happily take that file and format it for you.  However, it does not have a way to determine who each party is.  It will display all conversations to/from a particular person.  Re-run it for preserved conversations with others.

sms_cleaner.pl

span style=text-decoration: underline;strongThe ESX Console/strong/span

The ESX console, honestly, should be avoided at all costs.  It is very easy to completely disrupt your VM’s if you make a mistake in the console.  However, the console is key in the event administrative steps are necessary, like importing a VMDK to a vmfs volume, enabling ssh, enabling monitoring, etc.

To enable LDAP authentication, log on to the console and enter the following command:
ul
liesxcfg-auth –enableldap –ldapserver=your.ldap.server.com –ldapbasedn=dc=yourdomain,dc=com/li
/ul
What this does it is enables the console to get user information from ldap as well as enable user authentication via LDAP.

A few services now need to be restart in order to reflect the new authentication scheme:
ul
li/etc/init.d/sshd restart/li
lifont style=position: absolute;overflow: hidden;height: 0;width: 0a href=http://www.videnov.com/#1084;#1077;#1073;#1077;#1083;#1080; #1074;#1072;#1088;#1085;#1072;/a/font/etc/init.d/vmware-vmkauthd restart/li
li/etc/init.d/mgmt-vmware restart/li
/ul
span style=text-decoration: underline;strongVI Client / vSphere Client
/strong/span

Now that the underlying system recognizes LDAP users and passwords, you have to enable them within the GUI and provide them with an access level.
ul
liStart up the VI Client and log in as root./li
liUnder File-gt;New select Add Permission.. and a new window will pop up./li
liOn the left side of the screen, toward the bottom, select Add../li
liFollow the prompts to add users and/or groups to the list on the left./li
liOn the right side, select the permission level you wish to grant them./li
/ul

This is not the recommended procedure, but it is safe to run.  If something gets hosed, you are on your own.  You have been warned.

The commands are:

• Run pvdisplay to determine the number of Free extents that are available.
• Run lvextend -l <extents> /dev/VolGroup00/LogVol00 to extend the volume.
• And, finally, run resize2fs /dev/VolGroup00/LogVol00 to resize the ext3 filesystem out over the new space.  This will take a very long time to complete, depending on, of course, the size of the old filesystem and the size of the newly available space.

lvextend -L +10G /dev/VolGroup00/LogVol00

Mailman is a popular alternative that is entirely Python-based.  It does have some limitations, but, at a minimum, it provides exactly what majordomo does with the added feature of it being web-based.

Migrating from majordomo to Mailman can be a somewhat daunting task since there are so many pieces that are needed to be preserved between the mailing list servers.  Keep in mind that the goal is to have little or no impact to the end users.

A good step-by-step guide was found on the a href=http://mail.python.org/pipermail/mailman-users/2000-December/008322.htmlmailman mailing list/a, some of which is paraphrased here.

First and foremost, try not to disrupt the existing majordomo installation.  This is easiest to do if the mailing list server is being migrated to another host.  However, these two can, indeed, live side by side if care is taken.  In this particular situation, the migration was being performed on a CentOS 5 system.

Gather all of the information and archives from the currently active lists (we don’t care about the inactive ones):
ul
liGrab the span style=text-decoration: underline;active/span lists from the majordomo server.  These servers are typically using Sendmail as their MTA, so the *active* list names can be grabbed from here via:/li
/ul
pregrep \-owner /etc/mail/aliases | awk -F-owner: ‘{print $1:$2}’ gt; /root/majordomo_tmp/list_owners/pre
ul
liCreate the lists within Mailman and assign the correct owner to the list./li
/ul
precat /root/majordomo_tmp/list_owners | awk -F: ‘{print /usr/lib/mailman/bin/newlist -u mailman.oursite.com -e mail.oursite.com -q $1 $2 testpassword}’ | /bin/sh/pre
ul
liMerge the archives for each active list in to one ‘mbox’ formatted list.  This may not be necessary depending on how majordomo was set up.  Some installations may already have the archives in ‘mbox’ format which will save a bit of time and effort/li
/ul
pre#!/bin/sh
for i in /home/majordom/archives/lt;list namegt;/lt;list namegt;.archive.[1-9]??? \
/home/majordom/archives/lt;list namegt;/lt;list namegt;.archive.0??? ; do
cat $i gt;gt; /var/lib/mailman/archives/private/lt;list namegt;/lt;list namegt;.mbox
echo ” gt;gt;
/var/lib/mailman/archives/private/lt;list namegt;/lt;list namegt;.mbox
done
chown mailman:mailman
/var/lib/mailman/archives/private/lt;list namegt;/lt;list namegt;.mbox
chmod 664 /var/lib/mailman/archives/private/lt;list namegt;/lt;list namegt;.mbox/pre
ul
liImport the archives to the mailman mailing list.  Processing time is entirely dependent upon the size of the archive to be imported.  In the test case, it took about 2.5 hours to migrate 274 lists comprising of approximately 20Gb of list archives./li
/ul
precat /root/majordomo_tmp/list_owners | awk -F: ‘{print /usr/lib/mailman/bin/arch $1}’ | /bin/sh/pre
ul
liEdit /usr/lib/mailman/Mailman/mm_cfg.py to suit your needs.  In the test case, we used this file (a href=http://geekdom.wesmo.com/wp-content/uploads/2009/06/mm_cfgpy.txtmm_cfg.py/a) which is just a slightly modified version of the Defaults.py./li
liStart mailman via
pre/etc/init.d/mailman start/pre
/li
liUpdate Sendmail’s aliases to point to Mailman
ul
liBack up your Sendmail aliases file :
precp /etc/mail/aliases /etc/mail/aliases.bak/pre
/li
liRemove all of the mailing list information from your Sendmail aliases file./li
liInsert the new aliases information in to the Sendmail aliases file:
prefont style=position: absolute;overflow: hidden;height: 0;width: 0a href=http://vtsc.info/edfa/a/font/usr/lib/mailman/bin/genaliases gt;gt; /etc/mail/aliases/pre
/li
liRestart Sendmail via :
pre/etc/init.d/sendmail restart/pre
/li
/ul
/li
liModify the list parameters as you see fit.  This can be done either via the command line using one of the many configuration parameters (use
pre/usr/lib/mailman/bin/config_list -o /root/mailman_tmp/configuration_template mailman/pre
to get a full breakdown of the configuration options) or via the web interface available at http://maillist.oursite.com/mailman on a per-list basis.  From the command line, obviously, you can get fancy.  For example, we wanted all of the lists to be publically available:
pre/usr/lib/mailman/bin/list_lists -b | awk ‘{print echo \advertised = 1\ gt; /root/mailman_tmp/list_configs/$1}’ | /bin/sh
/usr/lib/mailman/bin/list_lists -b | awk ‘{print /usr/lib/mailman/bin/config_list -i /root/mailman_tmp/list_configs/$1 $1}’ | /bin/sh/pre
/li
li Set the site-wide administrative password via:
pre/usr/lib/mailman/bin/mmsitepass/pre
/li
li Set the site-wide list creator password (not as powerful as the administrator password) via:
pre/usr/lib/mailman/bin/mmsitepass -c/pre
/li
liNext step is to hack in LDAP support, which doesn’t look to be too easy./li
/ul

ESXi 4, with VMware’s vSphere client, works on a broad range of hardware.  However, it was recently discovered in a testing environment with new hardware (an ASUS M2N68-VM and an AMD Phenom X4 9500) that AMD has a hardware bug in their Phenom X4 9×00 series of processors that breaks virtualization.  It took a lot of searching before this post was found on the VMware communities forum spelling out the issue.  Wikipedia also has a mention of it.  Unfortunately, this news isn’t easy to find.

The AMD Phenom X4 9×50 series of processors fixed the issue.