The SATA controller has changed, and you'll need to update the ahci map file to get it recognised by VMware ESXi 5.5:
mkdir /tmp/ahci cd /tmp/ahci vmtar -x /bootbank/sata_ahc.v00 -o sata_ahc.tar tar xvf sata_ahc.tar rm sata_ahc.tar echo "regtype=linux,bus=pci,id=8086:9c83 0000:0000,driver=ahci,class=storage" >> \ etc/vmware/driver.map.d/ahci.map tar cvf sata_ahc.tar etc usr vmtar -c sata_ahc.tar -o sata_ahc.vgz mv sata_ahc.vgz /bootbank/sata_ahc.v00
If you want to only use DHCP from dnsmasq service, you need to have dnsmasq listening to port 0 with the
This is done in the file
Then reload the systemctl daemon, and restart the dnsmasq service.
systemctl daemon-reload /bin/systemctl restart dnsmasq.service
If you live in Luxemburg and want to share a 3G connection with a Wireless router, you’ll find out that no wireless router is officially supported.
Here is how I’ve configured an Asus WL-330N3G with a Luxemburgish Tango K4605 3G Key.
First, the onboard CD must be disabled on the 3G key. To do so, connect the key to your computer, and send the following AT command.
Note that I’m using a Mac. To be able to send
AT commands, I’ve used screen. From a Terminal:
mac:~ user$ screen /dev/tty/usbHuaweiXXX
Once connected, test the modem with the
AT command. You should receive a
Then disable the onboard CD with the following:
Note: To get back to normal, send the following command:
Once this is done, plug the Tango (Vodafone) 3G key in the Asus WL-330N3G wireless router, and use the
3G sharing menu.
Make sure that the wireless router is running the latest release of firmware.
In the bottom right hand corner of the web interface of the wireless router, edit the 3G parameters. Click on
more details next to the
Apply button, and choose the following to match the APN settings for Tango Luxemburg
- Location: Manual
- ISP: Manual
- APN service: hspa
- Dial Number: *99***1#
- Account: tango
- Password: tango
Here is a stupid command for a stupid me!
After some SAN maintenance, I figure out that I was no longer able to modify a LV on a RHEL 6.2 server, due to
Cannot change VG vgname while PVs are missing..
The LV was first set as a two legs mirror, but only shows up as a single leg LV after the SAN maintenance:
lvs -a -olv_name,vg_name,devices vgname LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices lv_orabin vgname lv_orabin_mimage_0(0),lv_orabin_mimage_1(0) [lv_orabin_mimage_0] vgname /dev/mapper/360060160da612e00b879dacb1857e111(15360) [lv_orabin_mimage_1] vgname /dev/mapper/3600601602c502e00424263f91957e111(15360) lv_users vgname /dev/mapper/3600601602c502e00424263f91957e111(0)
The previous output shows that
lv_users is not mirrored, but trying to mirror it leads to the missing PV error:
lvconvert -m1 -b vgname/lv_users --mirrorlog core \ /dev/mapper/360060160da612e00b879dacb1857e111 Cannot change VG vgname while PVs are missing. Consider vgreduce --removemissing.
To fix this, I probably don’t want to use the proposed solution (vgreduce), but the solution was in the following:
vgextend --restoremissing vgname /dev/mapper/360060160da612e00b879dacb1857e111
This has just made my day! ;-)
If you are used to send attachments by email using the mailx command line, you are probably used to
I’ve just spent some time trying to figure out what happened to the
sharutils package providing uuencode.
It appears that you no longer need it (for this purpose actually), as
mailx now has the ability to send attachments:
SYNOPSIS mailx [-BDdEFintv~] [-s subject] [-a attachment ] [-c cc-addr] \ [-b bcc-addr] [-r from-addr] [-h hops] [-A account] \ [-S variable[=value]] to-addr . . .
As previously stated, mailx is now able to attach files firectly to your emails, but, as a MIME attachment… And what if you want to process the email in an automated manner, let say, with procmail?
Well, in this case, you likely will use
Perl and the
Here is an example of a script saving the attachment to the
#!/usr/bin/perl use lib "/opt/my/compiled/perl-5.8.8/lib/site_perl"; use MIME::Parser; $parser = MIME::Parser->new( ); $parser->output_dir("/tmp"); ### Parse an input filehandle: $entity = $parser->parse(\*STDIN); exit 0;
Things are getting better, but what if you’re not able to use Perl to extract the attachment and have to use
Well, you can replace
uuencode by using
openssl to encode the attachment in
base64, as shown below:
TOATTACH="/path/to/file" DEST="email@example.com" (echo; echo "begin-base64 644 $TOATTACH"; cat $TOATTACH | \ openssl base64; echo "====") | mailx -s "One human readable subject" $DEST
TOATTACH="/path/to/file" DEST="firstname.lastname@example.org" (echo; cat $TOATTACH | uuencode $TOATTACH) | \ mailx -s "One human readable subject" $DEST