stevedoria.net

John Johnson Jr. of the LA Times reports that NASA investigators narrowed down the loss of the Mars Global Surveyor to a bad command sent to the wrong address. Johnson also reports, “The review also said the spacecraft’s onboard fault protection system failed to respond to the errors.”

Surely, NASA could afford to run through the procedure of sending the command on a simulation.

The New York Times has posted an obituary for John Backus. All recent computer science graduates have been exposed to John Backus’ work with BNFs, making him a legend like Djiskstra. John Backus makes up the Backus in the Backus-Naur duo. I admit that I did not remember Backus as the creator of Fortran, but the article discusses the importance of his Fortran work, which introduced new methods to make working with machines easier for people.

I find myself trying to make it easier for hardware engineers to work with a software interface. Here’s a description of a programming language in Backus-Naur form that I just wrote up:

statement ::= variable_declaration “;” | expression “;”

variable_declaration := type variable_name | type assignment

expression ::= addition | subtraction | assignment | operand

assignment ::= variable_name “=” expression

addition ::= expression “+” expression

subtraction ::= expression “-” expression

operand ::= numeric_constant | variable_name

Poor scheduling has been the bane of several projects with which I have had involvement. Ever since the one-month estimate that I gave for my first independent software development project, a shopping cart, a statement by Fred Brooks resonates continually in my mind. In The Mythical Man-Month, Brooks states, “More software projects have gone awry for lack of calendar time than for all other causes combined.” There are many things that are detrimental to projects, and Brooks suggests that the lack of time is the most significant factor that hampers a project and overshadows the total damage inflicted by all others.

Having learned and relearned the importance of good reality-based scheduling, I become squeamish when receiving a seemingly groundless estimate on project duration. In particular, I am very pessimistic about schedules that call for an entire project to be completed within a month. Conceptualization of a nontrivial system can easily exceed two weeks. Design will most likely require more than a week. This leaves implementation and testing with less than a week in a one-month schedule.

Two approximations to a feasible solution for the software procurement problem with a constraint of one month are the minimization of the product feature set and the minimization of system quality. These have served as candidates, though with strong resistance from project members, in the past. Betting against optimistic or baseless schedules is betting with the house.

Brandon Hutchinson provides a concise howto for chrooting SSH. For recent distributions of Red Hat Enterprise Linux (like CentOS), the following may also be needed in addition to Hutchinson’s Fedora Core procedures:

  $ cp /lib/ld-linux.so.2 /chrootedpath/lib/.
  $ chmod 666 /chrootedpath/dev/null
  $ chmod 666 /chrootedpath/dev/zero

Running ldd on the sshd binary executable will display the executable’s shared library dependencies. The first item on the list addresses a possible dependency that was omitted in Hutchinson’s howto. The absence of this file is a possible cause for a “/bin/sh: No such file or directory” error message to be displayed when connecting as the chrooted user.

Attempting to SFTP as the chrooted user may result in the connection being immediately closed. After logging in as the chrooted user, executing /usr/local/libexec/sftp-server may also result in a “Couldn’t open /dev/null: Permission denied” error message to be outputted. This is fixed by applying the second item of the preceding list.

Hutchinson’s shell script can be modified to incorporate the additional steps that are presented above.

I have dealt with multiple dedicated hosting and colocation service providers within the last three years. I maintain the servers at the colo where stevedoria.net is hosted, and I assist clients who do not receive their hosting services from me. Dealing with demanding clients and their always very restrictive budgets gave me experience in configuring software to push available hardware to its limits.

Having managed computers at colocation sites for multiple companies and being humbled multiple times through personal experience, I have never felt so annoyed by the problems that arose with hosting companies. I recently assisted a client transition their site from a third-party hosting company to another. I was naive to believe that there were two basic forms of hosting: dedicated and shared. The client signed up for Verio’s Managed Dedicated Server hosting. First off, they attempted to bilk the client by providing hardware that was inferior to the client’s previous server. Upgrading servers with the hope of gaining improved performance was a key motivator for the transition. I discovered Verio’s “mistake” after careful prodding around the system. The server used a crippled version of FreeBSD, and a lot of the common tools that readily provide information about the server was stripped.

I believed that the handicapped version of FreeBSD was also a mistake and the correct server would provide a version of FreeBSD that is fully functional. I was wrong. Installing server monitoring applications, which would allow independent review of bandwidth usage among other things, could not function on the server. Information regarding the number of bytes and packets being transferred that is usually found in ifconfig was removed. Network diagnostic tools such as Wireshark and tcpdump did not work either. It seemed that the server was missing device nodes that were needed by these tools, and either the recompilation of the kernel or the loading of kernel modules was necessary. Unfortunately, the programs to load kernel modules were removed, so compiling a new kernel seemed like the only feasible option. Lo and behold, the kernel could not be found.

I called up Verio’s technical support line to seek help with recompiling a kernel on their server. I thought I would be able to at least gain information on where the kernel was located in the case that Verio’s operators were unable to provide active assistance. The support line number that was listed on their site connected me to their sales office, which had a recorded message about their office being closed. I was frustrated enough to require technical support, and hearing sales pitches for additional services was the least desirable thing to hear. After digging through my email, I found a technical support number that worked. It took a great deal of constraint to communicate with Paul, the Verio technical support representative who answered my call.

I discovered through Paul that the kernel was totally inaccessible to all users, including root. At this point, I concluded that the supposed dedicated server is nothing more than a virtual machine with a convoluted version of a respectable operating system as a thin facade for an actual dedicated server. Verio Managed Dedicated Server just isn’t. Methods that increase resource usage visibility that would enhance Verio’s accountability are prevented. Security measures like FreeBSD’s firewall cannot be deployed. There is no telling of how the resource demands of other customers hosted on the same physical machine will affect the client’s Internet presence. There is no telling of how Verio’s restricted FreeBSD server will hamper a power administrator’s ability to diagnose and rectify future server problems.

I find myself making the most of what is provided to meet a client’s demanding needs once again.