Are a bad time to poke at your mail servers to fix a performance issue, as it seems it co-incides with the day VMWare decides to mangle the VM description for the mail server you are fixing :/
To those people who I host mail for, sorry it will be back ASAP, just playing it safe with the email and making backup copies of the data before I mess with anything else. Worst case this will be back up this evening some time.
Yeah a long name I know, but trying to get it stuck in Google so it will be most helpful.
I hit this snag and did a lot of trawling with little luck. Previously had no issues installing VMWare server, upgrade to Lenny, swap some hardware, decide to get it up and running and POOF! no dice!
Anyway I have solved it (huzzah!) and can finally goto bed 
It seems that the error message is related to the lack of .config and or Makefile in the headers. So a .config or Makefile in /usr/src/linux/.
if you have installed your headers :
apt-get install linux-headers-$(uname -r)
have build-essential installed have set CC to be gcc-4.1 yet still you get grief, heres what I found.
If you look in the headers path, you will see .config and Makefile. Yet no joy!, look closer, the Makefile is a damn pesky SymLink!!! this goes for most if not all of the buggers. What you need along with the headers is:
linux-headers-2.6.26-1-common
which should reside in the same directory as your headers:
ls
linux-headers-2.6.26-1-686
linux-headers-2.6.26-1-common
The SymLinks point into files in there, for some reason (possibly my own stupidity) I didn’t have it, possibly deleted it in a fit of disk space recovery before starting the build.
Hopefully that will be of use for someone out there, if not, I am sure I will find it useful when I next cause myself grief
Seems there is a new DDoS in town. Seeing requests for ‘.’ against my DNS servers from an IP. Every minute or so. This will return a list of root name servers from the hints file on the DNS server. Not a massive amount of traffic… unless you are the spoofed recipient of this and consider how many DNS servers are now sending you copies of their DNS roots hint file :/
Ideally I would like to be able to tell BIND to ignore any requests for ‘.’ alas I cannot find a way to do that (anyone who knows how to do this on BIND 9.3.x please let me know. My damage limiting hack at the moment is to zero out the hints file itself. So querying ‘.’ gets you a blank response. Doesn’t stop the problem but the amount of data sent is that bit less. My servers are not recursive and should only be responding for zones they host so it shouldn’t cause me any issues not having a valid set of DNS roots.
Hopefully some bright spark will pop up with a nicer solution to this before this starts happening en-masse.
update : An alternative to this is to put ‘additional-from-cache no’ in your bind options, you will need recursion also disabled, so only really for an authoritative server. Will stop your server replying from the cache and respond with a ‘refused’, which whilst still data, isn’t of the same magnitude as the roots hint.
Some twat decided to haxxor my blog.
Probably my own fault for having such an old version of WP on here. None the less not impressed.
Instead of this page you get an interactive interface for poking around and running and reading stuff on the remote system. I think I have gotten off lightly thanks to the joys of suphp.
The hack page actually lives in the database, and hides itself in some coded text making it a bit of a head scratcher to find. I read around on the web :
and discovered a load of dubious rows in my wp_options table :
| rss_0ff4b43bd116a9d8720d689c80e7dfd4 |
| rss_0ff4b43bd116a9d8720d689c80e7dfd4_ts |
| rss_17fd746cbaabc9c8492edcdc707a29c3 |
| rss_17fd746cbaabc9c8492edcdc707a29c3_ts |
| rss_503e5c96d032cbcd5e7bff1c20b85bbd |
| rss_503e5c96d032cbcd5e7bff1c20b85bbd_ts |
| rss_867bd5c64f85878d03a060509cd2f92c |
| rss_867bd5c64f85878d03a060509cd2f92c_ts |
| rss_encoded_html |
| rss_excerpt_length |
| rss_f541b3abd05e7962fcab37737f40fad8 |
| rss_language |
| rss_use_excerpt |
As I backup the SQL regularly and the site was screwed I took my usual brutal approach to it and just binned these rows. tada, site back. May have a look and see if anything else has changed… tho tbh, I think just updating to latest version is probably the best bet.
Also found a few extra plugins in the wp-content/plugins directory.. including a copy of the hello plugin and a larger /old version which was just full of nonsense. Again coded php :/
rather annoying but at least I seem to have removed it.
fuckers.
Joy of joys I have spent most of this weekend actually working.. for work… gah..
Thankfully it has been quite interesting stuff, and alas not all of it has lead to stuff being complete. I still have a system to rebuild, some tweaks to make and check over something else.
Both leading to potentially more work on other systems. All of which will detract from the new shiny work and project stuff I want to work on. Poo. Ah well this is the life I have chosen, get my head down, my tunes on and see if I can grind out some stuff.
Of course as always when busy, stuff jumps in the middle.. So Storage Expo needs to be visited on Wednesday, (need to book me a train for that! last minute as usual :/, and possibly a hotel, tho I haven’t yet decided if I should stay there Tuesday night.. probably be a plan TBH)
I am getting there organisation wise.. but still not quite there Here is to a fun week ahead
Gah, my poor G5 has IO limits 
Alas having time machine try and backup your DV editing system whilst you are streaming DV to it and or indexing the DV streams seems to push the poor little SATA drives a wee bit. Turning off iMovie and WHEEE much faster backup.. odd that really
Well spose the backups are a bit thin for this machine and it’s drives hold a precious cargo, so I don’t mind letting it finish its backup before I play more. Although, its doing a bloody good impression of a fan heater.. I can see why the G5 laptop never made an appearance, would need a set of asbestos trews to go with it
Yeah, already heard “There be Dragons” (No not 32’s Miss Jenny ).
Anyway I think I have a plan to perform this, its most likely a bit of a hack, but involves no perversions of file systems or databases themselves and should in theory provide a consistent and reliable ’snapshot’ of a database for a point in time.
Alas it is most likely going to be a bit intensive for larger databases but I don’t have any of those so meh Its a purely academic idea with most likely very few real world applications.
So what is it?
Simple.. in stages!
Simple eh and you can see why not really applicable to a large database. Obviously day end run whatever patch files etc through bzip/gzip/tar combo ready to be slapped on tape.
Now I just need to go play
Update Tested… and it seems to work ! WIN! Pointlessly OTT db backups here I come
Debian I love to hate. Given I use it daily at work and have done for the last 5 years now, I have grown to know it a little. I am no expert, I have never submersed myself in its pink swirlyness. I don’t love it that much and I hate it too much for that too.
Today was a hate day. Along with the weekends “why the hell is a broken version of an app in the STABLE release but the fixed working version in backports” discovery (clamav). This time its the cleaning up old box ready for redeployment. So clearing the cruft from it.
Whilst trying to remove mailman from the system I had a few errors from apt, so I tried with dpkg itself, even specifying –force-all with no joy. Seems that it wanted to shutdown mailman before removing it, fair enough.. if it was actually running.. and the state it was meant it couldn’t be started with some faff. As it was now in a removal state it wasn’t going to let me read it either. dpkg merrily spewed errors.
So hacky time.
In the path /var/lib/dpkg/info are a bunch of scripts. Looking there was a bunch for mailman. The executable flagged ones, especially ending in stuff like ‘prerm’ (pre-removal) caught my eye. A quick edit to add ‘exit 0‘ after the initial #!/bin/sh and all of a sudden those pesky tests are not your concern
It may fill your box with Jam. I dunno.. it got rid of that package is all I care about right now
I have been a lazy little boy and let my configs go all fallow and unloved. Spent a chunk of today tidying and fixing bits and bobs here and there. Net result, a mail server that’s a touch quicker, and also doing what it should be, and far fewer problems delivering mail from local stuff (like mailman).
Still a fair few bits and pieces to sort out with my little empire (such as proper monitoring) but getting there.
I have ended up with a bit of a mess in my XFS root! I have a directory full of illegal files and trash, it looks like some how inodes have become cross linked from some data files. This is somewhat of a pain as the box is up and running and I don’t want to offline it to repair it. Of course the way to repair XFS is with an offline filesystem.
Like that’s going to stop me trying. In the off-chance I manage to do this without rendering the file system jam I am going to document it here (plus may be handy if I need to do it again).
In my situation my root is very small in size (about 380MB), all of you who just have one epic root dir with everything in it, let this be a lesson to you. It is on an LVM Volume so I am sure there are possibly nicer ways to do some parts of this with LVM, but I have no unallocated space to make clones of volumes etc.
On my system I have a volume group called ‘primary’ and the root volume is called ‘root’.
An ls shows me the mess :
sulaco:/home/graeme# ls /etc/vmware.bork/pam.d/
001qr-RN-D 07Sd-Eu-H Di-H ? L
005Rn-Di-D 3TO-GM-H -GM-D ^ùì
008D6-E3-H 4aJ-Fc-D L
05Qb-4z-H 7SK-SD-D ? L
? 06fY-RJ-D AES (AdvA?d EnR·0¦ ?qSt0àard)?$? ? L
(I have renamed the directory to vmware.bork)
1st off, we need to get the current running FS as consistent as possible. So sync what’s outstanding and make it read only.
sulaco:/home/graeme# sync;sync;mount / -o remount,ro
Now, we have a static target (I hope). Lets get a nice block level copy of it whilst it’s not moving, I hate working on live stuff and much rather make copies of stuff I am about to break.
sulaco:/home/graeme# dd if=/dev/primary/root of=root.fs
720896+0 records in
720896+0 records out
369098752 bytes (369 MB) copied, 45.8338 seconds, 8.1 MB/s
We now have a file ‘root.fs’ which is a block level copy of our broken file system. Depending on your confidence it may be worth making a copy of that elsewhere, should the repair go horribly wrong you can always DD it back in place and be where you were when you started.
Now we have an unmounted copy of our broken XFS. We should now be able to use the -f flag with xfs_check to see what’s what.
(NB: If you get some error about there being changes and the log needing to be replayed, simply mount the file as a loopback device and unmount it again. You may need to use the nouuid option to be able to mount it. I will cover mounting the FS later)
sulaco:/home/graeme# xfs_check -f root.fs
agi unlinked bucket 38 is 96038 in ag 2 (inode=620326)
agi unlinked bucket 40 is 96040 in ag 2 (inode=620328)
agi unlinked bucket 41 is 96041 in ag 2 (inode=620329)
agi unlinked bucket 42 is 96042 in ag 2 (inode=620330)
agi unlinked bucket 44 is 96044 in ag 2 (inode=620332)
agi unlinked bucket 45 is 96045 in ag 2 (inode=620333)
agi unlinked bucket 46 is 96046 in ag 2 (inode=620334)
agi unlinked bucket 47 is 96047 in ag 2 (inode=620335)
agi unlinked bucket 49 is 96049 in ag 2 (inode=620337)
agi unlinked bucket 52 is 244 in ag 2 (inode=524532)
agi unlinked bucket 53 is 96053 in ag 2 (inode=620341)
agi unlinked bucket 57 is 96057 in ag 2 (inode=620345)
dir 894700 bad size in entry at 10
dir 894700 entry .. bad inode number 18158138244107078
dir 894700 i8count mismatch is 181 should be 1
agi unlinked bucket 18 is 338 in ag 6 (inode=1573202)
agi unlinked bucket 29 is 157 in ag 6 (inode=1573021)
agi unlinked bucket 58 is 80890 in ag 6 (inode=1653754)
agi unlinked bucket 62 is 19454 in ag 6 (inode=1592318)
link count mismatch for inode 524426 (name ?), nlink 3, counted 2
allocated inode 524532 has 0 link count
allocated inode 620326 has 0 link count
allocated inode 620328 has 0 link count
allocated inode 620329 has 0 link count
allocated inode 620330 has 0 link count
allocated inode 620332 has 0 link count
allocated inode 620333 has 0 link count
allocated inode 620334 has 0 link count
allocated inode 620335 has 0 link count
allocated inode 620337 has 0 link count
allocated inode 620340 has 0 link count
allocated inode 620341 has 0 link count
allocated inode 620345 has 0 link count
disconnected inode 894702, nlink 1
allocated inode 1573202 has 0 link count
allocated inode 1653754 has 0 link count
allocated inode 1573021 has 0 link count
allocated inode 1592318 has 0 link count
So, as I said.. broken then.
On with the repair then, xfs_repair -f (as we are using a file for our block device) should work.
sulaco:/home/graeme# xfs_repair -f root.fs
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
error following ag 2 unlinked list
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3 \Ð" in shortform directory 894700 references invalid inode 185706064904960>ßýÐPÏ
size of entry #0 overflows space left in in shortform dir 894700
junking 255 entries
corrected entry count in directory 894700, was 63, now 0
corrected i8 count in directory 894700, was 181, now 1
corrected directory 894700 size, was 25, now 10
bogus .. inode number (18158138244107078) in directory inode 894700, clearing inode number
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
corrected i8 count in directory 894700, was 1, now 0
corrected directory 894700 size, was 10, now 6
bogus .. inode number (0) in directory inode 894700, clearing inode number
- agno = 4
- agno = 5
- agno = 6
- agno = 7
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- ensuring existence of lost+found directory
- traversing filesystem starting at / ...
entry "pam.d" in directory inode 524426 not consistent with .. value (18446744073709551615) in inode 894700,
junking entry "pam.d" in directory inode 894700
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
disconnected inode 524532, moving to lost+found
disconnected inode 620326, moving to lost+found
disconnected inode 620328, moving to lost+found
disconnected inode 620329, moving to lost+found
disconnected inode 620330, moving to lost+found
disconnected inode 620332, moving to lost+found
disconnected inode 620333, moving to lost+found
disconnected inode 620334, moving to lost+found
disconnected inode 620335, moving to lost+found
disconnected inode 620337, moving to lost+found
disconnected inode 620340, moving to lost+found
disconnected inode 620341, moving to lost+found
disconnected inode 620345, moving to lost+found
disconnected dir inode 894700, moving to lost+found
disconnected inode 894702, moving to lost+found
disconnected inode 1573021, moving to lost+found
disconnected inode 1573202, moving to lost+found
disconnected inode 1592318, moving to lost+found
disconnected inode 1653754, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 524426 nlinks from 3 to 2
done
Few errors in there but its better than nothing I guess. Now to mount it and have a look around see if things match the existing root etc.
sulaco:/home/graeme# mkdir testroot
sulaco:/home/graeme# mount root.fs testroot -o loop
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Aha! Our 1st gotcha! whyever didn’t that work… following its advice and tailing the logs gets us :
sulaco:/home/graeme# tail /var/log/messages
Aug 24 16:45:15 sulaco kernel: Filesystem "loop0": Disabling barriers, not supported by the underlying device
Aug 24 16:45:15 sulaco kernel: XFS: Filesystem loop0 has duplicate UUID - can't mount
UUID conflict, simple to overcome, ‘nouuid’ as an option to the mount :
sulaco:/home/graeme# mount root.fs testroot -o loop,nouuid
sulaco:/home/graeme# ls testroot
bin data home initrd.img.old media proc srv tmp vmlinuz
boot dev initrd lib mnt root sys usr vmlinuz.old
cdrom etc initrd.img lost+found opt sbin tftpboot var
Much better. Have a quick look through this and check to see if the important stuff looks OK. Maybe diff some files/directories with your still mounted root etc.
Before making the crazy step, unmount the newly repaired filesystem.
sulaco:/home/graeme# umount testroot
Now, we have a fixed root file system.. its just not the one we are using. So, time to cross your limbs and dd it back. Hopefully the fact the mounted one is read-only should allow us to change the disk without too much hassle. I hope.
so here we go..
sulaco:/home/graeme# dd if=root.fs of=/dev/primary/root
720896+0 records in
720896+0 records out
369098752 bytes (369 MB) copied, 30.9349 seconds, 11.9 MB/s
Lets have a little look around…
sulaco:/etc# ls /etc/vmware.bork/pam.d/
sulaco:/etc# ls /lost+found/
1573021 1592318 524532 620328 620330 620333 620335 620340 620345 894702
1573202 1653754 620326 620329 620332 620334 620337 620341 894700
Well the trash has gone from the /etc/vmware.bork directory, and there are a chunk of lost inodes in lost and found… So far so good. Perhaps try running a few commands from /bin /sbin etc to check that all is well, as we haven’t reorganised the data I wouldn’t imagine there would be too much broken.
All that’s left now is to remount it read-write and go and have a nice lie down/brew.
sulaco:/bin# mount / -o remount,rw
(remember it’s mounted read only so no need to sync )
There we go, XFS root repaired with no rebooting, or downtime.
Think I will go and be chuffed with myself now for a bit and wait for this to bite me in the arse (If it does I will post here and let you know about it )
Hope someone else finds that useful, or at least interesting.
Well for me anyway. Got a bit fedup with tape swapping throughout Sunday at home with my DAT72 solution I had for my home backups. So I splashed out on a 2nd hand LTO 2 drive and 5 tapes on ebay. For £270 I think I got me a bargain. Its an external Dell PowerVault 110 with a Segate/Certance/Qualstore drive in it, came with 5 tapes and 1 cleaning tape (new).
Had some fun and games swapping cards around as the 19160 I had in the box initially only had a 50pin external SCSI connector, and this is a 68pin (and I have no 50->68 pin cables ) so had to fettle my 29160 out of my old server. All seems well and it’s currently happily backing up. Only issue I have is that I cannot get the datarate above 10MB/s so am shoe shining a bit. Source is capable of more, but seems I cannot get that rate to the drive.. I wonder if its down to IRQ sharing on the SCSI HBA or something…
Really need to rebuild this server box, its HDDs are full and it’s a bit lacking in RAM.. bloody computers its just always cost these days…
Checked this AM and there it is patch. Run the update app and the update is downloaded locally and then uploaded to the server. Simple.
Only gripe was that the updater claimed the update was applied, which it was, but never made mention of needing to restart the server. I had to manually restart the server, would have preferred a warning and then the standard “need to reboot to apply the update” type message.
But as thats the only gripe, it’s not a huge one. If you read the KB articles as the patch notes say, you will know it’s needed. Just I expected the reboot to be automatic as implied.
Still extremely impressed with the level of communication from VMware for the whole thing.
Seems VMware made a booboo, and have accidentally left in some expiry code into ESXi release. The bug prevents you from starting, resuming or vmotioning (?) a VM on the affected ESXi host.
1st off, very very high praise to VMware for being 100% upfront and informing everyone about the issue, I got a very nice email from them explaining the issue and providing a link to their KB article and also to a static version of the article as it is oddly being battered right about now
Seems the issue only affects VMs that are stopped or suspended, so I am not overly concerned at this moment as the VM this site is on and my mail server I have no intention on stopping any time soon. Suggested work around are to set the date back on the host to pre 12th August, which may cause problems for some hosts which have the VMs syncing time with the main host, if you don’t do this tho.. no foul.
VMware have pulled the ESXi Update 2 binaries from download to stop people grabbing a borken version (which is very honourable and wise) and are planning to release a fixed set of install binaries in the next few hours (planning to post progress reports every 2 hours too!), with a patch coming later. They give the reason for this as being they can produce the fixed binaries faster than the patch, which make sense to me.
Overall I have a nice warm fuzzy glow that VMware are out there looking out for their customers even if they are freebie scroungers like me. Of course I am sure they are not wanting to soil their excellent product (rightly so) and providing this level of after ’sale’ care just wins them more votes from me.
Applause to VMware, hope you keep up the excellent standards.
Having a shiny new box with an AMD 64 bit cpu (or 4) in is kinda nice, wraping that lovely hardware in VM is even nicer. However it seems that Debian’s kernel modules for XFS and possibly other distributions have issues. I have just attempted a filesystem expansion on one of my VMs and met with errors of :
XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument
Which was odd.. I have also experienced some wonderful Segfault Action on my other debian box when running quota, some googling revealed some issue with XFS and AMD64 kernel. So I thought as this box was a mail server its no big deal if its off for a few minutes. Switched it over to the AMD K7 kernel, and bingo, xfs_growfs works without issue!
Somewhat concerning, I couldn’t find a link to any bugs mentioning XFS via a brief google, but seems like there are quite a few. Does seem odd tho as I am pretty sure I was running a 64 bit kernel on my SPARC boxes, without issue. Will have to redo my webserver now as well, as that is going to need to have its disk resized soon.
More as a reminder to myself than anything as I keep doing this
Trying to run some script and get the following ? Trying to do an Apt-get install and it’s just barfing ?
Check if you have set any of your mounts with the NOEXEC option in fstab on Debian apt will run some scripts in /var for example, so being overly paranoid in here will just bite you on the arse
One thing I was kinda hoping to be able to do is something I have seen in VMWare GSX Server. Thats the ability to have VMs owned by a user and giving that user access to their VMs. ESXi being essentially ESX I thought ‘this should be a given and implemented really nice’. Alas it’s not. In-fact in standalone mode (which is the free version) its not possible.
I have spend quite a while trawling manuals and googling and mentally trying to will a permissions tab to appear on a VM to no avail. Without Virtual Centre it is not possible to provide user level limitations on VMs which is a shame, but understandable. It would be such a nice helpful feature for people who want to mass host others VMs that giving it for free would be shooting yourself in the foot. So alas, any users who I grant access to my ESXi box will have to think of it as shared hosting and just remember to lock their consoles
Its a pain, but at least one I can live with. Still massively impressed with the whole ESXi thing.
Well, VMWare ones do..
Seems they are not quite the same as your traditional block level ‘copy on write’ or netapp snapshots. Why is this bad ? Well it seems that VMWare snapshots record changes that are made to the disk after the snapshot is taken.. Great! but that’s the problem… they KEEP recording changes, ALL changes.. forever!!
You soon end up with a VM getting fatter and fatter and fatter.. until it’s out of space, your VMs are a tad wobbly. Ok, fine, lets bin our fat unwieldy snapshot.. ok, but to do that the ESXi server has to go and commit those changes to the VMs actual disk!, this takes time.. more time depending on the length of time the snapshot has been running for. Apparently it is possible to get the esx server to have a little tiz and become unmanageable with large snapshots.
EDIT As pointed out by Aid below it is most likely that a snapshot will grow to the size of your VM disk image and not beyond. I had simply not tested this myself, but makes most sense looking at it more clearly.
I am currently in the process of removing the one I attempted on this server, hopefully it will finish without wobbles. (I do so hate server wobbles). Once done I think I will put a label over the button on my monitor with “DO NOT PRESS” on it, just to make sure I don’t accidentally press the damn snapshot button again.
At this time ESXi seems to be behaving.. tho I cannot see any stats for the VM for this host, tho the host seems to be running fine. Hopefully ESXi is just busy, as the disk IO is pretty much maxed out.
Found a handy link for an alternative solution to getting out of the snapshot woes here
With my recent WoW guild swap and spending a fair amount of time getting my head around Joomla (something I recommend people look at if they are after a CMS), I noticed the creakyness of my current colo box. Its served me well Netra T1.. some 10+ ish years old about. (I haven’t had it for that length of time mind )
But new shiny things are afoot. This VMWare stuff is all very exciting and interesting and I really wanted to have a bit more grunt (especially when I host a retro party website for a friend which is using some python abomination as it’s websever and cms.. ik..
So I splashed out.. bought myself a 1U Dell SC1345 Quad AMD64 box at 2GHz with 4GB of RAM. With the recent news of ESXi being freely available too, I jumped on that and snagged me a license. Alas I ordered the Dell with VMWare Server and Debian in mind, so only one disk (software RAID plans). Of course ESXi isn’t going to do software raid so I quickly bought a Dell 5iR SATA/SAS RAID controller from Dell to fit, snagged a couple of drives from Aria (who managed to screw me around :/ ) and got set at some upgrades.
Alas I noticed the RAID card shiping note indicated it’s lack of cables.. GAH! no where on the site were they listed! Thankfully the kind bods at work had one extra kicking about from some miss ordered servers.. WIN! not the same model.. but hey. Added that to my box, alas with one cable being 2 inches too short!!
GAH! SATA Data extension I thinks! could I find one ? no chance.. thankfully whilst glumly wandering the isles of Maplin I spotted an adaptor for connecting internal SATA externally.. Perfect. Remove the blanking plate and I have a 6 inch SATA Data extension
So hardware ready.. ESXi next.. best install EVAR! put in disk, turn on, say yes a few times and BOOM box is rocking and rolling. Just connect to it via a browser, snag the Infrastructure manager from it, fire that up and off we go!
This site is now served from a VM running under my new ESXi server. Its certainly nice knowing I am not going to be wasting all the resources of this box. I will be absorbing my mail server into it next, once I have had some more playtime
If you wanna play with VMWare, go look at ESXi, it’s free ESX! and mostly made of win!.
I think I have too much (in some cases).
I spotted that I had some nice AniMusic 720p .mov files on my windows game machine, so I copied them to my file server so they could be played on the TV (Kids may like em). As I shutdown and went to bed, the thought struck me, just HOW many times were those 2 files stored….
Its a bit silly, as I have gone RAID 1 crazy with the price of HDDs these days, and the inclusion of a Time Capsule.. 7 would be the answer!! SEVEN! so I erm, don’t think I will be loosing them anytime soon.. I think I may go and delete the files off a couple of machines
There has been talk of confidential info on laptops, laptop theft and the fun and games that could potentially cause (For the record, I don’t keep company sensitive info on my laptop, so OI! laptop ninj0rs.. PISS OFF!)…
However, I wouldn’t like my personal files being in the grubby mits of aforementioned laptop ninj0r. So I had a look at the File Vault in OSX. Quite sweet really, cypher your home dir, base don your login. Multiple people on the same mac all have different crypts keeps you nice and secure. Win! Alas problems…
I have just started using Time Machine, (why the hell not). My laptop isn’t connected at home on a regular enough time frame to permit a scheduled backup, so I would like the funky win of Time Machine, problems solved, however, Apple have done the File Vault / Time Machine interaction in a sensible way. It will NOT backup the File Vault whilst it is mounted, instead it will only make a copy of the encrypted volume as a whole, thus retaining the security! TOP IDEA!.. Problems tho.. This makes it huge.. so not what I want to be punting across my wifi network. Also it only runs whilst the user is logged out! I don’t logout of my laptop and leave it on.
Ideally I would like to be able to tell Time Machine to just sack it and backup to my home storage in the clear, as the encryption is purely for protecting the data whilst it is in transit. Can’t see any option for this. Also would be nice if the File Vault could be set to encrypt SOME and not ALL the home dir (do I need my music encrypted?)
So, ok, mostly done the right thing.. but would be nice if there were a few options to enable people to do the less than right thing. I will have to see what else I can do I think…
DNS and BIND (5th Edition) by Cricket Liu