Giving file servers redundancy

So as I have mentioned before, I work for a 24 hour company and as a result complete redundancy of our systems is an absolute must.

I recently decided to set up DFS on our dedicated file server so that we can have redundancy of all our data.

Our current setup consists of a Hyper-V host running about 7 servers, one of which is a dedicated file server, and we have a VPN running through our router to an AWS VPC.

I fired up a new EC2 instance on AWS, joined the server to the domain (thanks to the VPN) and configured it as a secondary DC (more redundancy there!). I then added a new drive to the server and installed DFS Management on both our primary FS and the new Secondary DC (which will become the FS “hub”).

The first step in this process was creating a namespace for our shared folders, as it’s just basic redundancy we’re going for, I decided to go for the following namespace:

I then went through and added all of our shares, adding them to DFS in the process:

All I needed to do after that, was add the second DC as a namespace server and it created all the necessary folders there.

Aside from setting extra’s in terms of priorities, that’s all there really is to DFS! This is just a basic rundown, mind. I’ll do a start to finish config soon.

Doing network changes on a 24 hour company

Recently I decided that for my company I wanted to remove the terrible Remote Desktop system that was in place for home workers and replace it with a VPN.

The problem with this, is our company network was on the 192.168.1.x subnet, which was certainly going to cause problems with routing as most home networks are also on 1.x.

The first thing we did, was temporarily put all of the night staff on to mobile hotpots, and enabled our BCP plan to re route all of our landline calls to the 6 mobiles we have in the office.

The next step was reconfiguring the routers (we have 2, one is a primary and the other a failover) on to the new subnet, with new IP addresses. I felt doing this via serial would be safer. However HSRP also needs configuring via the serial cable. So I fired up PuTTY and configured HSRP as follows on the primary router:

interface ge0/0
ip address 192.168.200.251 255.255.252.0
no shutdown
standby 1 ip 192.168.200.254

Doing the same to the secondary router got them both connected. Awesome, that’s the internet back.

The next step is getting our switches on to the new IP range, connecting one by one to each switches web interface (they’re Cisco small business switches with no OOB connection), we changed the IP address to the 200.x range, keeping the last octet the same to make things easier for ourselves.

In order to get the night staff back online as soon as possible, I quickly threw my laptop on to the old subnet with static IPs and put our primary DC on the 200.x range, and reconfigured DHCP to hand out 200.x IPs. Now we can flip everyone back to the main network.

Tidy up time!
Now that people can work on the main internet, we need to move everything on static configs over to 200.x. Starting with the Access Points, we configured them individually (we have no controller), to 200.x and then started moving the other servers over, making sure that we can ping them and they can ping each other along the way.

Doing the same with the printers and other peripherals, all that was left was Group Policy references and DHCP reservations.

I did DHCP while having my colleague go through GPO’s and making sure file references were updated. Once that was down, we did a quick run round of all the machines, doing

gpupdate /force

to make sure that the machines picked up the new links.

One thing we did notice though, is that the shared drives didn’t automatically pick up the new IP address. We had to disconnect the drive and run gpupdate in order for them to map correctly.

Thankfully this was a success overall, and only took us about 5 hours!

More NS4600 changes

The system was reporting FS errors because of the fact I never had any drives initially plugged in to the system, I’m now running version 02.01.4000.16 of the Patriot Javelin S4 firmware on my NS4600 NAS fully. I have set it up with a 4x1TB RAID-5 and have just transferred all my data to it, SMB works, AFP works, I haven’t had a single issue (although I’m still yet to try printer sharing).

I did however initially have an issue where with the Patriot firmware, SMB wouldn’t start up at all (because I tried to flash Patriot to the internal NAND) and I had to flash the internal NAND with the official NS4600 firmware, and then still boot from the USB with Patriot. But this is out of the scope of this blog post so I won’t touch on it today.

I had one problem last to solve, root access. There was a root plugin released for later firmwares (the .v2 BETA I’m running was the only version I was able to get hold of) that allowed you to get root access over Telnet, but refused to install on to my firmware due to it being “built” for a new FW. In order to get round this, I used my knowledge of the encryption keys used to disassemble the firmwares and pull apart the plugin in order to change its config files to match a lower firmware. For those interested, here it is:
https://drive.google.com/file/d/0BxMokgOJbDnOc25UNDd5ZXRnQlU/view

Note this plugin will only run on the Patriot .V2 BETA firmware, and not any others, not even the NS4600 so don’t try it. If you need NS4600 plugins for root access, let me know and I’ll point you in the right direction.

Now it would seem I have finished customizing my NAS and done all I need to do… All that’s missing is a VPN plugin, and figuring out how to access the NAS from over the internet!

Anyway, hope this helps any of you with issues with your NAS, peace out!

Hacking the SmartStor NS4600 – Part 2

Here we go, my plan worked. I have been able to get some FW to boot from USB successfully.

I aim for this blog post to be more of a guide, than a “this is what I did” post.

So it turns out that the NAS I have is actually an NS4600P (the difference between the non-p variant and this one, is this one has a PowerPC processor) and there is another NAS which is just a rebranded NS4600P, the Patriot Javelin S4 which I noticed has a lot more… community support (in terms of repairs, hacking etc) so I used a lot of information gathered about that device and applied it to this one without many changes needed.

First off I grabbed myself a 2GB memory stick (formatted as FAT/16 not FAT32) and whacked on the firmware files for the Javelin S4 that had been extracted by a user that goes by the name of Senomoto on the Patriot forums on to the root of the stick. I then attached my serial cable, and booted up the system (completely spamming CTRL+C to get to the u-boot menu) and seeing what variables uboot was applying. This gave me all of the addresses I need to load the kernel/rootfs from elsewhere.

With the USB stick in the NAS, I ran the following commands to set up USB booting:
setenv load_ext_usb “run ramargs addtty mtdargs;usb start;fatload usb 0:1 1200000 kernel;fatload usb 0:1 1b00000 rootfs;fatload usb 0:1 1a00000 dtb; bootm 1200000 1b00000 1a00000”

setenv real_bootcmd “run load_ext_usb”

saveenv

(Credits to Senomoto for these)

Once the variables had been saved I just went ahead and booted the system, watching closely to the serial output and noting any errors. To my surprise the FW had booted completely fine, meaning that the S4 firmware, is again just a rebranded NS4600 firmware, making my life hell of a lot easier.

Thanks to the USB boot, I am again able to access the web configuration pages for the NAS, so I went ahead and threw in a small hard drive and created a brand new array with it (just a single drive in RAID-0) but I noticed I was still getting “File System Errors” and I currently can’t tell if that’s because there was no drive in any of the bays or it’s checking the internal NAND. So my plan is to let the array rebuild and see if I get FS errors. If I do, it’s likely the system is completely screwed (as it won’t even let me flash a new FW with filesystem errors). But we will go from there.

Hacking the SmartStor NS4600 – Part 1

So it has been a while since my last post, but I feel like this post will be worth it.

I recently acquired a free Promise SmartStor NS4600 NAS box that I thought I could use at home. So in my sheer excitement (and lack of research) and turned the box on, got everything set up and decided to set it up how I wanted it (oh how stupid of me, to think it would be that simple).

To start off I reset the admin password, logged in, attached it to my subnet and recreated the RAID array to RAID-0 (because screw redundancy). All was working perfect and the array rebuilt so I rebooted the system and logged back in to remove the old users from the box, this is where things went tits up. Apparently early versions of the firmware for this system suffer from a serious bug where sometimes deleting users or changing file permissions can render the device inoperable, meaning I can’t access the web interface, SSH, Telnet or configure the device properly with the utility. The only thing I can do is ping the device, or access safe mode to reflash the firmware. Luckily for me, this means the device is still in a semi-operable state. It’s worth mentioning that the NAS is stupidly designed in the fact that there’s no button or option on the web interface to actually reset the whole device to factory defaults.

According to my trecks around the internet, the decryption key for plugins and firmware was discovered and the same across several of Promises NAS boxes, this gave me an idea. Why don’t I create a custom firmware that will A) run SSH as root so I can connect and see what’s going on, or B) Create a CFW that will force reset everything to default.

So I started off by installing Linux in a VM, downloading the smallest FW from their site, decrypting it, unpacking it and reversing the process to see if it will still flash. Apparently it’s not that easy, while the encryption key was correct, it would appear that the files are obfuscated further and I was unable to extract the resulting archive straight away.

It turned out that Promise thought that adding a long series of 0’s to the beginning of a .tbz archive would stop people breaking in to it, that’s not the case. Now I have a .tbz containing app_jfs2, fix_script, kernel, rev, rootfs and usr_jffs2. Now I need to readd those zeroes and see if I can re-encrypt the file to flash it.

After two days of trying, it look like the bcrypt that promise use, is a modified binary for their systems, unfortunately I don’t have a working system to be able to pull bcrypt from the system, so serial is the only other route. I have ordered this cable to use:
https://thepihut.com/products/adafruit-usb-to-ttl-serial-cable

I will update with part 2 when it arrives.

Peace.

MLPostFactor – Upgrading to Mountain Lion

So as you know from my last post. I managed to install Lion on to a HP Compaq nc6320, while I was happy with the system, the lack of hardware acceleration bothered me. This was more to do with the lack of a DSDT, rather than dodgy kernel extensions. Thankfully I was able to come across a Compaq 6720s which has an upgraded chipset (GMA965 with X1300 graphics processor) and better support for Hackintosh builds. Using the similar method as before, with iAtkos ML2, lots of patience, and pre-done research, I came across a kext pack and DSDT’s for this system. GREAT!

So there I go, I throw in the iAtkos disk and do exactly the same set up as before:

32bit boot,
32bit RTC,
VoodooHDA 2.7.3
PS/2 and boot with cpus=1.

When the installation completed, I was expecting to have the same problem as before with the lack of a backlight but instead I was surprised to see that the display (sort of) worked out of the box. All that was wrong with this, was the resolution was stuck at 1024×768, which caused an extremely grainy “feel” to the display which I didn’t get with the 6320 and there was obviously no hardware acceleration. Thankfully, no tinkering was needed in Single User Mode or Safe Mode like on the 6320, all I had to do to get this system set up right was to open up Kext Helper and install all of the kexts in the pack.

Kext Helper run its install perfectly and prompted me to reboot, so naturally I did. I was expecting to see my shiny new (non-grainy) display come to life, but instead I was still plagued with the crappy 1024×768 resolution. It came to me that the Kexts may not be directly compatible with my system (Apple hardware tends to have different ID’s) so I was able to run a few commands in terminal to binary patch the Kexts to look for my HWID’s and viola! Hardware Acceleration!

The good thing is, this laptop has about 99% supported hardware (from the chipset to the ethernet), the only thing again not supported is the internal wifi (those damn Intel A/B/G NIC’s). Nontheless, there’s a hacked BIOS floating around that removes the whitelist.

Good, enough about Lion. Let’s move on to Mountain Lion!

My set up for this consisted of a 2GB Memory Stick, an 64GB Memory Stick, the app store version of “Install Mac OS X Mountain Lion.app” and lots and lots of time on my hands (too much, according to my girlfriend). For the 2GB I transferred the kexts I need for this system (see download at the bottom of the post) and the 64GB I used myHack to prepare an installer for the system. Please note that when you’re using myHack, choose the generic bootpack as we can boot vanilla.

After installing through myHack you’re going to want to boot back in to myHack and run the “Remove troublesome kexts” patch, or you’ll get KP’s. After a reboot you’re going to be presented with your shiny new ML install. Oh yeah, it works. But as what happened with Lion, Hardware Acceleration refuses to work, and we are stuck in 1024×768. So now it’s time to prepare MLPostFactor.

What we need to do, is copy the “Install Mac OS X Mountain Lion.app” to the Applications directory and fire up Disk Utility. Where OS X is installed, I created another 20GB partition called “Install” (the name doesn’t really matter, it’s just to make things easier). Upon opening MLPostFactor I was greeted with a nice menu asking where to prepare MLPF to, I chose the “Install” drive and let it do it’s thing. The install it’s self took about 30-40 minutes while it prepared the modification of the system and the Kexts. This is only stage 1 though. I rebooted my system and Chameleon kindly presented me with the ability to boot from the Install directory, so I did. I was given the normal OS X installer display, and I selected “MLPostFactor” from the Utilities menu and the expected menu appeared again. It asked me what OS X I version I was “hacking”, all the way up to 10.8.4, which I knew I hadn’t installed, I was on Vanilla 10.8.0, so I quickly booted my regular system and installed the 10.8.5 (yes, .5) combo update and proceeded with the MLPostFactor patch.

After MLPostFactor had modified my ML install, I was getting serious Kernel Panics from all over the shot, VoodooPS2Keyboard, AppleHDA, and loads more. So I did what I had to after the fresh install and removed the troublesome kexts through myHack but it proved not to be enough. Out of curiosity I just ran the “Repair Disk Permissions” from Disk Utility on my myHack drive and that seemed to resolve the rest. Although I must note, I had to manually remove ApplePS2Keyboard and AppleHDA in Single User Mode.

Now back in to Chameleon, I try starting with the arch=i386 and to my surprise, I see the “RELEASE_i386” string in verbose boot! It’s working! I get back to my desktop and install the kexts on my 2GB stick as I had to before, and patch them with my HWID’s.

That’s it, a full day to hack my way in to ML. If you ever use MLPF, remember that you’re essentially running “Mountain Lion Developer Preview 1” under the bonet. MLPF is a dirty hack, but I have a stable system with hardware acceleration.

Also, as promised, here’s the Kext pack for the 6720s:
https://mega.co.nz/#!hhgmABrZ!mtqADe8vmSeAbvf56afTBQTSgtxlsMzCzf9QQB90l1c

New Hackintosh Project

For years I’ve been wanting a Hackintosh system. I remember a few years ago, I had a Dell Optiplex GX280 system, absolutely terrible it was, but it was free so I can’t complain. Anyway, I came across a video on YouTube of someone who managed to install OS X 10.5 on it, since then I became hooked on trying to install OS X on my systems.

My current project system is a HP Compaq 6320 Notebook which has the following specs;

– Core 2 Duo T550 @ 1.6GHz
– 3GB RAM
– 100GB HDD
– Intel GMA950 Chipset

Thankfully, according to osx86project.net, my system is compatible with 10.7 and 10.8, but the damn laptop doesn’t have a dual layer burner so I’m having to stick with 10.7.

As we speak (00:01 AM / 1st Oct 2014) I’m doing a dummy install of iAtkos L2, it’s just a barebones install to check to see if I can get the system to boot. I’m been having a lot of trouble even getting the installer to boot without a Kernel Panic. I managed to fix it by disabling any internal devices other than the core ones (USB, Sound card, LAN, etc). This allowed me to get in to the installer and get going. Also, it turns out that having Dual Core enabled in the BIOS causes a kernel panic, so it needs to be disabled.

Initially after the install, I got an issue with AppleRTC not being able to start, this makes a Kernel Panic appear, which is never good. To get around this I had to do (another) reinstall from scratch. This time I selected the 32bit version of the RTC patch & select the 32bit bootloader patch. OS X is now booting.

Even though OS X booted, my backlight won’t work. Due to the fact that the OS X version (10.7) is too new,  it no longer supports the GMA950 chipset that is in my system. Thankfully, there’s a patched AppleIntelFramebuffer.kext and AppleIntelGMA950.kext ported from 10.6 that works on my system. To install it I need to transfer the kexts over to a FAT (not FAT32) USB stick and boot in to single user mode with the -s flag. At least the backlight works in single user. Then we do the following:

“mount -uw /” – Mounts the filesystem as R/W.
“mkdir /Volumes/USB” – Created a folder we will later mount to.

Next we need to find out what the system sees the USB stick as, to do this we run the following command BEFORE plugging in the USB stick:

“ls /dev/disk*”

This should return a list of results such as “/dev/disk0 /dev/disk0s1 /dev/disk0s2”.

Next we plug in the USB drive and run the command again to see what changed:
“/dev/disk0 /dev/disk0s1 /dev/disk0s2 /dev/disk1 /dev/disk1s1”

We can tell from this that /dev/disk1 is the USB drive and /dev/disk1s1 is the FAT partition. Now we need to mount it:

“mount_msdos /dev/disk1s1 /Volumes/USB”

and VOILA! The drive is mounted to /Volumes/USB and we can view the kexts on there. All we have to do, to install them is change directory to /Volumes/<Hard drive name>/System/Library/Extensions and run the following commands to remove the old kexts and copy the new ones:

“rm -rf AppleIntelFramebuffer.kext”
“cp -r /Volumes/USB/AppleIntelFramebuffer.kext ./”
“rm -rf AppleIntelGMA950.kext”
“cp -r /Volumes/USB/AppleIntelGMA950.kext ./”
“reboot”

There we go, the GMA950 chipset is recognised by OS X and the backlight works. Excellent, but we are still plagued by the issue that enabling Dual Core in the BIOS will cause a kernel panic. This one took me a while to figure out. All that needs to be done, is we need to download DSDT editor and go through it to extract your DSDT from your BIOS (guides on Google) and then we can apply the GMA950 Laptop patch to the DSDT and set Chameleon to boot using it. All that’s left, is to enable dual core and boot with the cpus=1 flag (tell’s Chameleon there is only 1 physical processor) and you’ll notice that OS X recognises both cores of the system.

There we are, debugging and fixing a Hackintosh laptop.