A blog about my rantings, including Games, Game Development, Gaming, Consoles, PC Gaming, Role Playing Games, People, Gaming tips & cheats, Game Programming and a plethora of other stuff.
Most of us are well aware of how much heat electronic equipment puts out, what can be less intuitive and harder to balance is the problem of heat from hard drives.
Good organised machine operation, with clearly defined device usages, easy control of units across machines, sites or different customers is the key, therefore enter stage left a nice fat label to hold all the details of the unit.
Except, this label acts as a heat blocker, reducing the surface area of the metallic or foil labelled drive as delivered, reducing the area across which the heat from the unit can dissipate, and even causing uneven heating, or heat wearing over time.
The net result... For my project, a high mechanical drive mortality rate, which I simply could not explain, nor model or explain in the man lab.
Only a trip to see how these machines were being employed sufficed to show the problem, label after label applied and reapplied, a drive on within a machine was untouchable it got so hot. My solution, put a number on the drive in marker pen and link that number to a database entry with all the drive information.
This solved the heat death problem.
But it also opened up the scope of the information being transmitted, with access to any smart phone the customer could then look up the information, so could their designated engineer, they need never bother me - which is again key to efficient business practice.
Like-wise those not wanting the quite useful information on the harddrive to be public, simply have their information about the drive secured away behind a password on the site, or even more simply not on the site.
Options and solutions, that's how I see this problem benefiting projects going forward... If only we'd not been putting label after label on for year after year.
Today I've come to a totally virgin installation upon a server, this was for a work group I've got to head up whom are looking at pushing MySQL with Python. And things initially went wrong...
I stipulated they had to use Python3 and thought everything else would be fine for them to install with Pip3, so...
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install python3
sudo apt-get install python3-pip
sudo apt-get install mysql-server
Everything looked fine, their user could install packages through Pip3 and they had Flask and a few other things and were flying. I used the mysql client on the command like to test I could add a few items and also ran...
sudo mysql_secure_installation
To do the basic hardening of the database, so everything was fine... Right?....RIGHT?!?!
No, not exactly.... "I can't get mysql.connector".... Came the cry.
And they were right, it reported a myriad of build issues and could not install. I took a look... NIGHTMARE!
It appears the installation of mysql.connector via Pip3 depends upon Protocol Buffers from google for the latest version of mysql.connector... Which the Pip install didn't sort out, at least not easily... Luckily I run a whole gaggle of virtualized machines, so I could quickly spool up a new instance and try a few things out...
This is just the basics, so our installation will now depend upon git, autoconf, automake, libtool, curl, make, g++ and unzip, most all your standard distributions will contain packages for these, we use -y just to skip any permission requests.
sudo pip3 install flask
hostname -f > hostname.txt
The next step is simply a couple of items for our project, we're going to use Flask to provide a restful interface, and the "hostname.txt" is simply to remove our need to call "hostname" again later.
sudo apt-get install -y mysql-server
sudo mysql_secure_installation
Our next step is to install and secure the MySQL service.
sudo ldconfig
cd ~
Generic code now, to simply reload the library list and change to the home directory.
git clone http://github.com/google/protobuf.git
cd protobuf/
./autogen.sh
./configure
make
make check
sudo make install
This is the build of protocol buffers from google, so we pull it from their github repo, we move into that folder, prepare and configure the build, then make the whole build. By far this is the LOOOONGEST instruction, on a single core 1GB equipped virtual instance this took around 45 minutes.
Once complete we simply need to reload the libraries again...
sudo ldconfig
However, protocol buffers are still not installed within Python, so we are still in the "~/protobuf" folder, we now need to go deeper, into the python folder and perform the setup installation under python...
cd python
sudo python ./setup.py install
When complete we again need to reload the libraries...
sudo ldconfig
And the final, secret sauce, is to actually install mysql connector through pip3 with protocol buffers...
I have just run across an issue which has me slightly baffled... Sending the build down to my automated server and it started coming back as failed, panic ensued, so that I started to then do builds on my local Visual Studio instance... (which is VS2013).
Now, this code is perfectly working, has been fine, released and tested for... Since about 2011.
This is how the error shows up...
Taking a closer look...
We can see there are suddenly a bunch of unresolved externals, specifically the definitions of a bunch of functions.
There is NOTHING wrong with this code, indeed, the work around to get a build to complete is to comment out any one of these functions....
Rebuild, and it now fails on that specifically missing function body.
Finally, re-enable the code and do a further rebuild... and everything completes perfectly...
Consulting the internet about this one, as everyone here has drawn a blank, and one person suggests that this is a miss-match between the Byte set setting of the project (Multi-byte) and any libraries being Unicode. However, I have no third party libraries... The mystery only deepens.
A full fresh check out of the code, still fails, a full clean fails, a rebuild fails, rebooting the machine has failed. None of the fixes has made a difference, and more problematic is that the failure happens sporadically.
This is the software side of modifying my Dell Poweredge 2950 (Model II) servers to be much quieter.
It WORKS! But please beware, THERE ARE POTENTIAL RISKS IN ALTERING YOUR BMS FIRMWARE, IF YOU ARE READING THIS, IT IS ADVICE ONLY, ALL AND ANY ACTIONS YOU PERFORM ARE AT YOUR OWN RISK! Just because it worked for me, doesn't mean you will be successful.
Part 1, shows how I added 47ohm 0.5watt resistors to the power (red cables) on each of the four internal fans. I'm yet to modify the power supply fans, but I will.
Part 2, is my success video recorded at 3am last night when I was very tired, and had everything working.
And this, Part 3 is to cover my complete solution in how to do the software (BMC) firmware flashing.
This was burned to a DVD ROM, and as you can see in the image, I had to re-fit a DVD into the server as I have three servers, but only one DVD drive... DOH!
Next, I booted into Text Mode, so when the boot menu appeared from the DVD, I pressed Escape before the auto boot timed out, and selected to boot in Text mode. Once booted, the login is "root", with no password.
My first command is to ensure the ipmi tools are installed, python, wget and rpm are on that image, but for completeness to the source material I include them in the installation:
Once complete you can check the ipmi sensors are working with:
ipmi-sensors
You will get a huge list of all the sensors on the board.
Next you need to download the BMC firmware, to anywhere on the machine, you don't need any storage, the Live CD boot you're using will work fine just with RAM in the server!.. So no worry about overwriting any disks or data!
This will extract a load of information, then ask you how many fans, or what model to edit, for the 2950, with four system fans and two power supply fans, I selected option 3. To give me six fans to modify.
It lists each fan and their threshold value, so now select the fan by entering it's number, so try 1 first. Then enter a number, now if I recall the default 2250 threshold is a value of 25. I tried various values, but the best I found to modify for the resistors I'm using was 22, this gives a new minimum RPM of 1650 for the fans. And I never saw any fan drop below 1800 RPM.
23 is 1750 RPM as a threshold, but I thought that too close to the lowest RPM I'd observed before starting this software mod.
So, 1 through 6 all selected and 22 entered for each, you then write this file back with the 'w' command. This will repack the payload/bmcflsh.dat file with your new values.
Armed with this modified dat file you therefore need to flash the firmware, THIS IS THE STEP WHICH CAN BRICK YOUR MACHINE, PROCEED AT YOUR OWN RISK!!!
We're still in the bmc folder created before, so change nothing after altering the payload with the script, and you type:
And as you can see in my full video coverage, this worked for me.
I hope this helps, below are the references I went to, but I must have read about 15 different posts, dozens (if not hundreds) of the comments to piece this together. The biggest problems I had from other posts was understanding the problems using Ubuntu and other distros, they don't work. There are problems with the libstdc++ libraries, and then the i686 installation and all manner of hoops and tricks I tried.
Centos 6.4 i386, is the only live DVD image I've been able to use... and this all work easily.
The main instructions I followed were from Martin Denizet, however, even his post has issues and it not clear how to get the right distribution.
I also tried to follow RatzBlog, but was thwarted at every step by the OS's I was using, even trying to use Centos 6 didn't work with his instructions.
I've had a annoying moment with the Oracle Java Updater, we have a system which though not using Java can run applications using Java, our system however is all seamless, there's no desktop and it boots into a managed environment for display. Trouble was the base disk we have had had the java update enabled, so about 50 seconds after starting the desktop changed to an Administrative mode asking for permission to update Java.... SIGH!
So this morning I've spent about half an hour figuring out a fix, because we can't seem to remove the Java update service. No problem, lets change the setting to disable it... So I fire up explorer, and there is the java Updater in the system task tray...
See, there it is... And you can right click on it and access the Properties...
And hey look, there's an option to NOT do updates... Lets select that....
Oh look, an apply button, I'm not a rookie, so I'll click that for good measure.... and then OK...
*Whistle*... *humm*... So lets go back in there and see what its done...
Holy mother fucking god the setting is back on... Thank's Larry, this is really good stuff...
How you actually this off, is to disable the whole updater/deployment tool... So go into your User AppData directory, so my username is "Xel" so the path is: C:\Users\Xel\AppData. This is a hidden folder, but just type it in to the start box, so if you're "judy"... C:\Users\Judy\AppData, and now we can go into: "LocalLow" and then "Sun" (yes Oracle fuck up the installer and still have the balls to name the folder "Sun").
Next you go into "Java" and then "Deployment"... Now we're past the gravy and against the meat, you should see a file called "deployment.properties"... Open that in a text editor and change the "deployment.javaws.jre.0.enabled=" from "true" to "false" so it looks like this:
deployment.javaws.jre.0.enabled=false
And reboot, now the deployment tool won't even start - let alone bug you or update the java runtime.
