Friday, November 25, 2011
If you've ever been involved with Linux Server Administration than you'll be more than aware of the many and varied automation/configuration options out there such as 'Chef', 'Babushka', and 'Puppet'. I've recently been working on similar technologies but to better comprehend and implement them I've had to review how the current systems work and their capabilities.
'Puppet' seems to operate in a client/server architecture using so called 'manifests' which are basically a set of instructions pertaining as to what actions you would like to complete. For instance, the remote installation of a package, the creation of a file, the setting of a certain set of permissions and so on. The 'manifests' themselves are then compiled (checked for syntax and other errors) and then applied to relevant 'nodes' within your network. Due to its relative maturity it is often available in most of the popular distribution repositories.
'Chef' has obviously been more Debian orientated. It took a while before I actually found a set of RPMs for my system. Prior to that though, I tried creating RPMs using the GIT repository with a set of autobuild 'Ruby' scripts. However, due to the state of the respositories of the time the build seemed to be broken. I used this as a learning opportunity with regards to RPM packaging (I used to create DPKG packages years ago for another project and have done some minimal RPM packaging. DPKG are basically 'ar' and RPM are basically 'cpio' archive files respectively if you're curious (much like the ZIP and other archival format)). I didn't do any research prior to testing my theories prior to test my problem solving abilities. Basically, symlinks aren't a viable means of dealing with naming issues in packaging. Copying files/directories (though this would violate best practice) and changing of version strings in the SPEC file are the more 'valid' option. As indicated in the SPEC file itself RPM is very 'Makefile' like in the way that it is structured. In fact, if you've ever written a 'Makefile' you'll be very much at home. Use 'rpmlint' in order to check for possible problems, 'rpmdev-extract' to extract a SPEC file from an existing SRPM, and 'rpmbuild' with relevant options in order to build an installable RPM.
Obviously, I found a relevant repository later on but it was very interesting getting a better idea of the process of creating RPMs. Check out 'alien' and 'checkinstall' if you have time which, by the way is an easy manual Perl install if you can't find the required package for your distribution. There is a web based interface that seems fairly sparse, a Command Line Interface (CLI), as well as what seems to be an extensive set of online 'recipes' to allow for all sorts of remote configuration, with support for Perl as well as support for automated provisioning of servers. Note that this extra functionality seems to come at the cost of some simplicity. There are a myriad of tools that are used, certificate systems that need to be setup, and unlike 'Puppet' you will definitely need to read through at least the Quick Start documentation in order to use it. Even then, the instructions make extra assumptions... Also, as with any other large, complex Open Source project its in constant state development and may have 'issues' from time to time.
'Babushka' seems to be a work in progress and feels like a stripped down version of a more complete configuration management system. Even the documentation is incomplete at this stage. However, it deals with most of the more important issues such as remote installation of packages, dependencies, and remote configuration.
If none of these options appeal than its fairly easy to build a custom configuration/automation system using Python's 'paraminko', Perl's 'Net::SSH', and Ruby's 'Net::SSH' libraries.
Wednesday, November 9, 2011
With all manner of configuration (CLI as well as GUI based) tools available to us now with regards to firewall configuration sometimes its hard to justify learning or knowing raw IPTables rules. Recently, I had to do some revision for a project that I've been working on (it involves automated generation of firewall rules). Some of the materials that I used included the following.
I recently picked up a book on Java certification (it was on sale). Obviously being Java there was a lot of coverage with regards to OOA, OOD, OOP, UML and so on. One of the more interesting sections was regarding was so called, 'Design Patterns'. Basically, a while back some computer scientists discovered that often certain problems/programs followed a similar pattern. Moreover, you could use these (as long as you recognise and are aware of them) patterns to reduce time/effort spent on designing/building new programs by using templates of these patterns. These templates ultimately became known as 'Design Patterns' and cover everything from development of GUI applications to layout of elements on a webpage.
While Windows is not the most secure Operating System in the world its certainly the most convenient. I used to install literally everything that came off the cover discs of magazines just to see what they were like simply because installation/configuration/removal was so simple. The Internet opened up the world even further. Over the last few years, 'smartphones' have become increasingly popular and tweaks/mods have made them almost as functional as desktop computers. My first foray into the Android world was a HTC Tattoo. To really exploit its capabilities though I've been exploring the the Android ADK/SDK (note that the 'HTC Dream Composite ADB Interface' driver is required for you to work with ADB and you'll need to have the 'Android ADK/SDK Platform-tools' package installed for you to do anything really interesting). Its essentially a Linux/UNIX platform with a suitable GUI on top and you can install all the same types/classes of programs that you would otherwise do on a fully fledged computer. The real difference is that unlike a lot of other platforms this one has basically been made for 'tweakers' and as such development of complementary software/hardware is significantly higher than most other platforms that I've come across. In fact, interfacing with the real world via robotics is easily possible via off the shelf kits at your local electronics store.
Tuesday, November 8, 2011
One of the things that I like to do in my spare time is tinker with computer software/hardware. Recently, I came across a product design/implementation that I thought should never have occurred/existed. Perhaps it was a one in a million case but based on my research it wasn't. It was a HP Pavilion dv2000.
Based on what I was told the working system was left in storage (inside a house so thermal/weather issues shouldn't have really been an issue) and hadn't been touched in several months. When it was turned on, all the LED's lit up but the machine didn't seem to 'boot'. There was nothing on either the LCD or an external monitor. Research and intuition thought that it had something to do with the discrete graphics chip (Nvidia) but I couldn't be sure until I had opened/examined the machine.
If you've ever opened up a laptop you've probably figured out that it is a pain and they often have design compromises with regards to accessibilty, cooling issues, and so on. A tip for those who attempt to disassemble this machine, go for the top/middle screws, then attack the left side of the top panel first and then attack the right hand side of the top panel after turning the screen towards you temporarily (you'll understand why if you ever try this). Then remove the keyboard and finally seperate the main shell/panels after removing the relevant screws.
When I finally took a closer look at the graphics chip and the connection to the mainboard I noticed that some 'balls' were completely flattened and obviously could not have been connected to the mainboard. Moreover, some balls ended up being in contact with others. Removal/reshaping of damaged balls was obviously a possibility but as I've previously discovered (and documented in this blog) 're-flowing' is only a temporary solution. A 're-ball' is the only real medium/longer term solution since its an inherent design fault that never should have existed.
Obviously, I tried a re-balled mainboard. However, after re-connecting everything I discovered that the lid switch which is used to detect when to suspend the notebook was dead which led to backlighting issues and is another known design fault with this particular notebook. While a fix is possible longer term it is likely to fail anyhow and the ability to hibernate can still be accessed by using the power button. Research indicates that the 'best solution' is bypassing the problem by merely disconnecting the lid connector to the mainboard.
At the end of all of this I discovered that the power switch wires had come loose. I didn't realise was how fragile something like this was and how difficult it was to solder using a general purpose iron (though I eventually got it). From a practical perspective the wires are too small to strip easily (unless you have specialised equipment). In fact, I used small nail clippers! Thereafter, you'll notice that you must apply a coating over the wires in order for the connection to remain stable after re-assembling the laptop. I tried liquid electrical tape but while it is a good insulator it isn't as strong you would really want. Moreover, there are time issues associated with drying/curing.
Normal tape is possible but I found that it lacked 'adhesive power'. I finally tried, 'industrial strength adhesive tape'. It reminds of 'gaffa tape' but is more pliable making it easier to fit around gaps and wires. Personally, it feels like a cross between liquid adhesives and tapes. Brilliant stuff and but not as thick as 'gaffa tape' which may cause panels to be slightly out of kilter when re-assembling the machine.
Once the laptop was re-assembled you may find that device drivers may need to be updated. I discovered that I needed to manually force the Conexant HD Audio drivers to be used in order for them to work. Windows/software based hardware auto-detection just didn't work.
- an obvious continuation on my previous religious research: http://dtbnguyen.blogspot.com/2017/09/religious-research-notes-16-random.htm...
- many people are often critical of choices that are often made in other countries. If you think carefully about it, massive loops have bee...
If you're like many others on the planet you probably can't be bothered purchasing a new piece of software in order to test an appl...