- Before we begin, I am assuming you have GCC, kernel-devel, if you do not; go to https://wiki.centos.org/HowTos/I_need_the_Kernel_Source to get kernel and the rpm build parts.
- Go to link.sandisk.com, register, and login
- Browse to the software download page, https://link-app.sandisk.com/Home/SoftwareDownload
- Download the “iomemory-vsl4-184.108.40.2067-1.0.src.rpm” source package
- In a terminal, change to the directory you downloaded it to
- Extract the contents of the RPM to disk
- That gives us some metadata and a tar, extract the contents of the tar.gz file
tar xvzf iomemory-vsl4-220.127.116.117.tar.gz
- Change directory to the kernel modules folder
- Using your favorite file editor, edit kblock.c
- Edit line 2592
- Save the file, and quit the text editor
- Compile the kernel module
- If that completes without errors, then install
sudo make modules_install
- Let’s add the module to the running kernel
sudo modprobe iomemory_vsl4
- If you have issues, you may need to do “sudo modprobe -r iomemory_vsl4” to force a reload of the module if one was already present
- You should now have the fio in /dev/, or after installing the utils from the Sandisk site, see the card under “fio-status”
I was very excited to see Susan Kare borrow of of the mini Macs from a friend and give it a shout out on Twitter! These kind words from someone responsible for a lot of the original Macintosh design are quite humbling. 🙂
HipChat 4 has recently come out, and then shortly after it was released to my companies internal HipChat server. Being a Linux user I hoped that the aged HipChat 2 client was finally updated for Fedora or Red Hat or CentOS 7 so I could just use yum to install it. When I went to the download page the old yum instructions were replaced by only Ubuntu/Debian instructions! After playing around with the Debian package and getting it to load, I thought I would look at the repo a little more. Low and behold, Atlassian is making a yum repo! Just not publishing instructions on how to use it! The downside is they seem to not be signing the repo, but the code below works with yum to download the latest version.
sudo bash -c ‘cat > /etc/yum.repos.d/hipchat.repo << EOF_hipchat
sudo yum update
sudo yum install hipchat4
This week I had a Dell PowerEdge R510’s iDrac completely die on me; I attempted repairs with several utilities that Dell gives out on their site and all of them ended with failure. I thought it might have been because I upgrade the iDrac from an old version to the latest, without components like the BIOS or NIC, that the iDrac communicates with, being upgraded as well. After upgrading everything, iDrac still was not working, after a few days of messing with it, I found out through piecing together several sites how to force the iDrac in recovery mode to do a TFTP repair, writing a new image to it.
The system used the Windows iDrac Updater, which stated the update had competed successfully. I then, remotely, told the system to reboot; it shut down and never came back up. When I physically went to the server, it was at the BIOS start screen stating “Error Communicating with iDrac. Press F1 to continue, or F2 for System Setup.” In restarting the server I found that “System Services” were disabled. Then the system would go through normal boot sequence, but when it tried to communicate with the iDrac it would fail then restart the server. After restarting, it would allow a full boot, but would give that same “Press F1 to continue, or F2 for System Setup” message. Thus the server would not boot without physical intervention at the machine.
This is a Dell PowerEdge R510, I attempted to upgrade the iDrac from 1.3.* to 1.6.5.
We need to get to the iDrac’s serial recovery mode, and then we can recover the system.
- Reboot the system, and after the system resets itself for not being able to reach iDrac go into “System Setup”, the F2 key
- Hit down until you select “Serial Communication”, enter that menu
- Set the following settings:
- Serial Communication : On With Console Redirection via COM2
- Serial Port Address : Serial Device 1=COM1, Serial Device2=COM2
- External Serial Connector : Serial Device 1
- This could be Remote Access Device, but that gave me problems (I may have had a bad serial cable)
- Failsafe Baud Rate : 115200
- For the 11G servers this is the default baud rate
- Remote Terminal Type : VT100/VT220
- Redirect After Boot : Enable
- Then rebooted the system. I got Windows to start by manually hitting F1
- At this point you need to go to support.dell.com, lookup downloads for your system, then under “Embedded Server Management” there is “iDRAC6 Monolithic Release 1.97” (or whatever version is newest)
- There are several versions, for my system I got “iDRAC6_1.97_A00_FW_IMG.exe (50 MB)”
- After downloading, running this file will extract “firmimg.d6” and a readme file.
- The readme has no useful information in it, it just tells you to search for the user guide
- The “firmimg.d6” file needs to be placed on a TFTP server that the iDrac can hit
- Using Putty in Windows I connected the COM2 at 115200 Baud, this is the iDrac being redirected. Connect to your systems Com2 however you can
- Note all this is being done on the server and nothing is done on a other machine, I had TFTP running on this Windows system
- Hitting enter should show a recovery menu
- Unfortunately I did not save pictures of the recovery screen, some of the next menu options may not be the exact wording
- I had DHCP on the network my iDrac was sitting on so I hit 9 to get a IP address, this can also be set manually
- Hit 7 to change the TFTP server IP address
- Now hit the option that says “Firmware Upgrade”, this will go to the TFTP server specified, download the firmware, and reinstall all pieces of the iDrac from that file. It takes about 5 minutes.
- Keep in mind you are in your OS, for me Windows, while the iDrac and its system upgrades and reboots
- After it reboots successfully the recovery console stops getting data, I was next to the server, when the iDrac reboots the fans go to full speed then calm back down. That’s how I was able to tell it restarted
- Now you can use the RACADM commands if open manage/iDrac tools are installed, or reboot and you should see “System Services” back online, then you can change the IP of the iDrac like normal
Everything should work now and the world is happy!
Recently I updated my Windows sudo program and added a command for Super Conduit, this is what I call some tweaks that you can make to a Windows Vista+ system. This allows someone to copy sudo.exe to a systems, system32 folder; then after running “sudo cmd” you can run “sudo /write” so add ls, ifconfig, and superc as a option in the command line.
Superc has options of enable, disable, and show. Making it easy to run. 🙂
Newest build is always here https://github.com/daberkow/win_sudo/raw/master/sudo/sudo/bin/Release/sudo.exe
Due to the high latency of the lines between my works offices, file transfers can be slow. There are settings in Windows Vista+ systems that can allow the TCP window to grow, and allow much higher utilization on these lines. I call it Super Conduit. This may be possible on *nix systems, but the way this tweak works is that it tells the other side it will be doing this tweak. That means that both sides have to be at least Windows Vista Kernel, (Server 2008 works) that also means that linux file servers will not work because them seem to be linux machines with SMB. This should be done over wired connections, because the packet loss on wireless hurts these connections more than anything else.
With the “autotuninglevel” change, I have seen speed changes from a 1megabit a second line go to 150-200 megabits a second.
WARNING: Windows Vista/7 IP stack can not handle changing this setting and using normal connections, meaning once this is done usually the internet stops working until the setting is reversed. Windows 8+ seems to have no problems with this setting, and the internet; it just makes Win 8/8.1 more awesome than it already is, which is pretty awesome.
- Login under a administrator account to the Windows machine
- Open ‘cmd’ as a administrator
- Title bar should be “Administrator: C:\Windows\System32\cmd.exe”
- “netsh interface tcp show global” will show the current settings of your machine
- “netsh interface tcp set global autotuninglevel=experimental” enables the majority of what you need for faster transfers, all you will get back in response is “Ok.”
- Another setting I have used in the past is “netsh interface tcp set global ecncapability=enabled” this adds a flag to the packs that tells routers “I dont care if I get slowed down, please dont drop me completely”. The problem you run into with large TCP windowing is one dropped lowers the TCP window size a lot and slows the connection making it a lot more spiky. This command doesnt always help, but setting it hasnt hurt in the past.
- The “rss” receive-side scaling state should be set to enabled, that should be the default. This allows the receiver to do these types of conenctions.
- When you are done your transfer just run “netsh interface tcp set global autotuninglevel=normal”
Windows 7 seems to act oddly when starting to use this setting, so I would enable it then restart the machine. I believe that cached sessions already in progress do not take the new setting.
Default window size: 65536 bytes * 8 = 524288 bits
73ms latency between cross country offices, 524288 bits / 0.073 seconds = 7,182,027 Bits throughput, theoretically. 897,753 B/s, max.
This setting increases that window size to something larger, much larger, and thus gives better speeds. The only interesting downside is that since the TCP window is big, if a packet is then lost, TCP resizes the window to a much smaller setting; forcing the window to climb again.
I am the type of programmer/IT person who enjoys having all my experimentation of systems done inside a virtual machine. That way if I break something, I can easily role back the virtual machine or just delete it. As seen in my last post, I recently built a new NAS. The original plan was to turn my old server into a Proxmox or ESXi box, the downside to that plan I found out quickly; the old box used DDR2, and at this point to get DDR2 memory it is quite expensive. That, along with my worry of power usage on the old box, I decided to give another solution a try.
After researching around I found my local Fry’s Electronics had the Intel NUC in stock. This is a tiny tiny PC that can take up to 16GB of RAM, has an Intel Core i5, and only uses 17 Watts. The box also has Intel vPro; what is vPro you ask? vPro allows you to remotely manage the system, so I can remote into it without buying a fancy management card, I can also remote power the box on and off, or mount a virtual CD. not bad for a ~$300 box. The model I got, DC53427, is a last gen i5, so it was a little cheaper, at the cost of having only 1 USB 3.0 port. It came with a VESA mount, so the NUC could be attached to the back of a monitor, that was a nice feature. I got USB 3.0 enclosure for 2 older 500GB hard drives, and used those as my storage. I installed Proxmox on the system since my work has been starting to use that software more and more, and this was a chance for me to learn it.
A quick note about Proxmox to those who have not used it, I had come from a VMWare background so my work was my first experience with Proxmox. It is a free system, the company offers paid subscriptions for patches and such, without that the web page bothers you one time when you login, and you just dismiss the message. The software is a wrapper around KVM and some other Linux virtualization technologies. It can handle Windows and Linux systems without a problem. The interface is completely web based, with a Java virtual console; if you don’t update to the latest patches the java console can break with Java 7 Update 51. The software works well enough. There are still some areas that is needs improvements; in VMWare if you want to make a separate virtual network you can use their interface, on Proxmox that’s when you go to the Linux console and start creating virtual bridges. But once I got everything working, it seemed to work well. I don’t know how long I will keep it without trying another system, but for now it is nice. Since the system relies on KVM, it can do feautres like Dynamic memory allocation, if a VM is only using 1 GB of ram but is allocated 6, it will only take 1GB at that time. Also KVM can do deduplication of memory, so if two VMs are running the same OS, it only stores those files in memory once, freeing up more memory space.
I ran into one problem during install of Proxmox, the NUC is so fast, that it would start to boot before the USB 3.0 hard drives had been mounted. After searching around everywhere I found a fix on http://forum.proxmox.com/threads/12922-Proxmox-Install-on-USB-Device; adding a delay in the GRUB boot loader allows enough time for the system to mount the LVM disks correctly and then start. At first I just went to the Grub boot menu, hit “e” then added “rootdelay=10”, to the “linux /vmlinuz-2.6.32-17-pve root=/dev/mapper/pve-root ro rootdelay=10 quiet” line. After the system loaded I went into /Boot and added the same entry to the real Grub menu. Now I had a Intel NUC with 1TB of storage and 16GB of RAM. I could have used the NAS with iSCSI, but that was a lot of config I didn’t want to do; along with, I was setting up some Databases on the system and didn’t want the overhead of using the NASs RAIDZ2 at this time.
I have been using it for a few weeks, and its a nice little box. It never makes a audible level of noise (although it does sit next to its louder brother the NAS). Down the road if I want more power I can always get another NUC and put Proxmox into a clustered mode. These boxes keep going down in price and up in power, so this can grow with my needs.