Remove /home Partition on CentOS

During my experiments with building a seedbox, I noticed that CentOS created a separate partition for the /home directory. Since I was building a seedbox at a cloud provider, I wanted the entire disk as a single partition for large torrent downloads.

Below is an example layout on a default install of CentOS 6.5:

The following commands will remove the /home partition and resize the root one:

Running df-h again will show that we have a single partition for /:

Now we still need to edit /ect/fstab to prevent CentOS from trying to mount a non-existent partition on start up. Delete the line that corresponds to the old /home partition; in my example its line 10:

Deluge 1.3.6 Seedbox on CentOS 6.5

I’ve recently been experimenting with using a seedbox; I built one using CentOS 6.5 and Deluge. The original guide I followed used a repo that only had Deluge 1.3.5 and later through some googling I found a repo for installing 1.3.6.

First add the repo for Deluge 1.3.6:

Add the following lines:

I also needed the repo for the geoip package which is required for deluge; my CentOS install at home needed it but a CentOS cloud server I tried didn’t:

Now we can install geoip and deluge:

Create a user to run deluge:

Set deluge daemon and webui to start automatically:

Add the following lines:

Now deluge will automatically start and run under seedbox user. Don’t forget to add rules to iptables for port 8112 which is the default port for the deluge webui.

deluge_webui

Iptables and Fail2ban Duplicate Rules

For a while I always wondered why fail2ban sometimes put in the same rule twice under iptables:

It turns out that when fail2ban service starts, it inserts the fail2ban-ssh rule at the top of your iptables rules; so if you did save of your iptable rules with the fail2ban-ssh rule already inserted, iptables loads its default rules (with fail2ban-ssh in it) and then fail2ban adds it again when it starts.

To fix this, I deleted the fail2ban-ssh rules from iptables and saved those rules; now when my server boots iptables loads without the fail2ban-ssh rule and fail2ban adds it when it starts.

Hackintosh Build Update and Gallery

It’s been over a week since getting my Hackintosh up and running; ever since downgrading to v2.4.14 of the AppleIntelE1000e kext I haven’t had any issues. Everything works and it feels like a real Mac.

Below are some pictures of my build; I installed a Noctua NH-U9B SE2 for as CPU cooler and added a pair of Noctua NF-S12A PWM fans at the bottom. Everything is arranged to blow up from the bottom. The NF-S12As are controlled by PWM and set to ~900 RPM; unfortunately the Z87E-ITX doesn’t appear to support voltage based controls for 3 pin fans attached to the CPU fan header. I set the CPU fan to run at full speed and used the low noise adapter to lower the CPU fans to ~1100 RPM.

My Experience with Hackintosh (ASRock Z87E-ITX and OS X 10.9.3)

My early 2009 Mac mini had recently died and I decided to try building a Hackintosh to replace it instead of buying a new Mac mini. The current Mac minis have not been refreshed since 2012 and are still using Ivy Bridge CPUs.

I had an NCASE M1 that had been sitting in my closet for the past six months so it seemed like a good time to finally put it to use. I was originally going to use a Gigabyte H87N-WIFI or Z87N-WIFI board based on the recommendations from TonyMacx86’s Buying Guides but a friend of mine had an ASRock Z87E-ITX he was not using; I went with that board instead to keep the build cost low.

The build components are:

  • Intel Core i5-4440S
  • ASRock Z87E-ITX
  • Crucial Ballistix Sport 8GB (2 x 4GB) DDR3 1600 Low Profile
  • Intel X-25M 120GB SSD (taken from my dead Mac mini)
  • Slim slot loading ODD (also from my dead Mac mini)
  • Corsair CS450M 80 PLUS Gold PSU
  • NCASE M1

While waiting for parts to arrive,  I prepared the installer using my Macbook Pro by following the instructions at http://www.tonymacx86.com/374-unibeast-install-os-x-mavericks-any-supported-intel-based-pc.html. Since I was downloading Mavericks from fresh the App Store to make the Unibeast installer, it was already updated to 10.9.3 – so I didn’t need to update after getting my Hackintosh up and running.

After receiving all of the components,  the first thing I did was flash the BIOS of the Z87E-ITX using a beta bios found at http://www.tonymacx86.com/general-hardware-discussion/117344-z87e-itx-updates-15.html#post762323 – looking through that thread you will see user WonkeyDonkey has done most of the work in figuring out how to hackintosh the Z87E-ITX.

Now I was ready to try installing Mavericks. I had my monitor connected to the ASRock via Displayport; I found that after the BIOS screen that Unibeast installer screen was just black. Normally you would see something like this:

usb

This is the screen where you press Enter to boot from USB or type in other boot parameters if you have issues reaching the installation. I also tried connecting the monitor via DVI and HDMI; both of those connections allowed me to see the Unibeast installer but would kernel panic every time despite the boot flags I tried. I left the monitor connected via Displayport and despite not being able to see anything I was still able to just hit Enter at the black screen and proceed to the Mavericks install. After completing the Mavericks install, I found that I could not boot off the installation using the Unibeast USB stick; I got a kernel panic every time (it was also tricky trying to select the install and type boot flags since the screen was completely black). Eventually it dawned on me that there was something different about the Unibeast USB environment and the new install of Mavericks sitting on my SSD; Unibeast has an Extra folder under / which contains kexts that are needed for it to boot properly on most systems in order for you to run the install. So I decided to try making the Extra folder on the Mavericks installation and copy over some of the files:

After doing this I could finally boot from the Mavericks installation and run Multibeast with the following settings:

multibeast1

I removed my Unibeast USB and restarted Hackintosh;  it booted correctly from the SSD and the boot loader was no longer showing a black screen. Everything seemed to work pretty well and I started reinstalling my apps. Then I realized I didn’t set up the audio. Unfortunately I’m not sure exactly how I got the audio working. I forgot to install the ALC1150 kext during the first run of Multibeast; I opened it again and chose just the ALC1150 and “Optional EFI Installed Bootloader Support”. After the reboot the audio was still not working. Then I tried running Multibeast again with ALC1150 and the DSDT.AML that is included in the zip with the 2.30A bios from the post I mentioned earlier. This just made my Hackintosh freeze at the Apple logo so I had to boot from Unibeast USB and use the Terminal to delete DSDT.AML from my /Extra folder. After doing this and booting into Mavericks again I found that the audio was working perfectly. Weird.

So far it appears to be stable and everything I have tested works: Bluetooth pairing with Apple Wireless Keyboard and Apple Magic Trackpad, ethernet, audio, hardware monitoring via iStat Menus, Intel SpeedStep and even Sleep (although it seems it will not wake up via Bluetooth, need to push power button to wake it up).

EDIT:   My Hackintosh appears to hang during heavy network loads and it appears the version of AppleIntelE1000e I used is unstable (see http://blog.thireus.com/tag/appleintele1000e-kext). I’ve installed v2.4.14 instead and it seems to be ok.

How to Update Unlicensed XenServer 6.2.0

Since XenServer 6.2.0, Citrix has made all of the features available for free; however to receive support one must purchase a license. I was always under the impression you could not update XenServer 6.2.0 because it is always disabled through XenCenter but today I found out you can just apply the updates manually.

Copy the update files to your XenServer via your preferred method or use wget to download them directly. Next run the following command:

After this command finishes, it will output the uuid of the patch you just uploaded; on my system I could just tab complete the uuids in the next command:

Reboot your XenServer and the patching is complete.

Fifth Freedom