Unlinke Apollo, Orion will touchdown on land

Early tests of the Orion landing phase...I just read an interesting article. With the Constellation program re-using so many of the clever Apollo-day concepts, I was under the impression that Orion capsules would splash down into the pacific, too. But I was (probably) wrong.

NASA engineers plan to do Orion touchdowns on land – just like the Russian Soyuz capsules. While it is challenging to do a land touchdown, it has a number of advantages. The Orion capsule is reusable (planned to be usable for up to ten missions). A splashdown in salt water means a lot of corrosion potential and thus a number of problems. It also requires an expensive fleet of recovery ships. So NASA has its preferences. On the picture, you can see testing of airbags that should absorb some of the remaining energy after the descent (though it is not expected to be much, Orion glides down on parachutes).

The landing area is supposed to be in the western Unites States. That comes at no surprise, a lightly populated area is definitely a plus for such an endeavor.

An ocean splashdown, however, is yet not fully ruled out. NASA keeps this option in case it is needed.

If you’d like to dig down into all the details, I recommend this Scientific American Article.

Happy Thanksgiving!

I wish a happy Thanksgiving to all my US readers! As it looks, most NASA folks will also enjoy a nice four-day weekend. Processing flow on space shuttle Atlantis STS-122 mission seems to be so smooth that only very limited work is scheduled for now until Sunday evening. It is really nice to see that the engineers worked so well that this is possible.

As far as me is concerned, I do not have a holiday over here but obviously there will not be much to report. So do not expect too many STS-122 related news. Except, of course, on the upcoming ISS spacewalk (November, 24th), which is critical for an on-time launch of Atlantis.

Enjoy the holiday!

recent rsyslog changes

I am back to my routine of posting rsyslog changes. You may also imply that this means I am actually developing some things (and not just writing about it ;)). After I had a somewhat slow start today, things evolved quite nicely this afternoon. If I did not overlook anything important, I even managed to complete the “clean unload process” for loadable modules. That also brought me back to good working knowledge of the code. Actually, I am at least a day ahead of my schedule. But, of course, I’ll check if I overlooked something – but that’ll be tomorrow.

So on to the promised change log (it also covers some past days where I had not reported):

2007-11-19
– applied gssapi patch from varmojfekoj – gss-api is now supported
– added some debug message to ommysql
2007-11-20
– added user doc for gssapi patch from varmojfekoj – thanks!
– bumped version number to 1.20.0, because of new gss api functionality
2007-11-21
– begun to look at dynamic module unloading – this is currently a hack
and works with the mysql module only (which is the only one, so there
is no problem in practice. But it would be good to begin to do it right ;)
– added new modExit() entry point to loadable module interface
– added an identifier to command handler table – need to identify which
command handler entries need to be removed when module is unloaded
– added support so that linkedlist key can be used for owner handle
– enhanced llExecFunc to support deletion of list elements (on behalf of
user function being called, slight interface change)
– enhanced linkedlist class so that list elements can now be deleted based
on the key value they have
– created entry point so that CfSysLine handlers are removed on modExit()
– some cleanup
– modules are now correctly unloaded and de-initialized

going back to rsyslog coding…

As promised, I have started to look at the rsyslog code this morning again and done so in an effort to enhance it. My first target is unloading loadable modules in a “well done” way. So far, this is a hack that does only work because ommysql (and probably a postgres module basing on it soon) does not use some of the interface functionality. Namely cfSysLineHandlers do not work with the current code.

So what I am set now for is doing it right and making sure that a loadable module can be cleanly unloaded under all circumstances. That, of course, requires some interface changes, but nothing major (keep in mind the interface is not yet finalized!). This work provides the basis for upcoming work, which will utilize many more loadable modules for other functionality, too. So it is a critical task.

I have to admit, though, that I think I need another day or so to get fully re-acquainted to the code. There was really a toll from my absence and I begin to notice it ;)

ISS Crew successfully completed Spacewalk

The ISS Expedition 16 crew wires the Harmony module in Space
The international space station’s expedition 16 crew successfully completed an important spacewalk yesterday. It was needed to get the ISS ready for the arrival of space shuttle Atlantis, which delivers the Columbus space lab. This spacewalk, as well as another one scheduled for November, 24th, is needed to be able to attach Columbus. So successful completion of these tasks is a critical perquisite to launch STS-122.

The spacewalk was threatened by a problem with the spacesuits, which thankfully got cleared a few days ago. The ISS spacewalking schedule was not affected by the problem investigation.

This series of spacewalks is needed to attach the Harmony module to its permanent location. Harmony was delivered during Discovery’s STS-120 mission. It could not be attached to its permanent location because that was used as the docking port for Discovery. So it was stowed at a temporary place and has been removed after Discovery departed. Yesterday’s spacewalk, as well as the upcoming one, is dedicated to rewire Harmony to the station, so that the module is fully functional. In December, Atlantis will delivery the Columbus module, which will be attached to the Harmony module.

Visit NASA’s space station page for a detailed report on the spacewalk.

Countdown demonstation test for STS-122

Astronauts get suited during the terminal countdown test demonstration (TCDT). Here: Astronaut Rex WalheimThe terminal countdown demonstration test for Atlantis’ STS-122 is being carried out at Kennedy Space Center. During the test, astronauts and ground crews practice count down procedures including emergency procedures that will protect the astronauts during a mishap immediately before launch. This includes a ride in the basket evacuation system as well as driving the emergency escape tank (which, in popular rumor, is always an astronaut’s favorite). The astronauts also try on the launch and entry suites, as can be seen on the picture above.

In NASA‘s latest information on the shuttle home page I noticed a slight slip in launch time. I now says 4:31pm and I think it previously was 4:38pm. But I guess these seven minutes don’t really make a difference. So, everything looks still quite well. If this is another as-schedule shuttle launch in a very successful 2007? Let’s hope for the best…

And here is the relevant quote from the NASA shuttle home page (they don’t archive it, its a shame):

It looks a lot like launch day at NASA’s Kennedy Space Center in Florida as the crew of mission STS-122 put on their pressure suits and get ready to climb aboard space shuttle Atlantis. However, the work is all part of the countdown dress rehearsal designed to get the launch team and astronauts set for the real thing on Dec. 6.

The crew of seven men, including two from the European Space Agency, will follow their normal launch day routine including riding in the astrovan to Launch Pad 39A and taking their places inside Atlantis.

They will sit inside Atlantis as the pretend countdown winds down. The engines will not ignite, of course, and the astronauts will practice emergency escape procedures on their launch pad to conclude the drill.

Atlantis is targeted to launch December 6 at 4:31 p.m. EST on its 11-day mission to the International Space Station.

rsyslog- what’s next?

I posted an outline of my next actions on the rsyslog mailing list and would like to share it here as well:

I have thought about setting up a full lab for GSS-API before carrying on. For now, I have decided to NOT do that. I am sure that the contributors have tested it quite well and the code that I have reviewed looks excellent.

So I will pull it in as is and wait for some feedback from the field (with the assumption “no feedback” equals “OK”).

I will then begin to look at the loadable module de-initialization. This is not really clean in the current release, but that’s no problem because modules never get unloaded. However, in the long term we need this to be clean.

The mysterious segfault issue is still dangling. I was hesitant to do any larger-scale new development without fixing it. But given the fact that it is extremely hard to find, and obviously happens very seldom, I’ll continue developing. I am right now looking into upgrading the dev machine to an x64 OS, where most of the problems happened. My hope is that I will see a segfault during further development work and then hopefully be able to tackle it. I still think that the segfault must be well understood and fixed before I go into some serious multithreading redesign. As such, unfortunately, this issue still holds some of the work scheduled for the next *major* version.

I thought I give you an update here in my end (will also post this to the blog for the others). Any feedback/suggestion is highly welcome.

Test of Orion Escape System

model of Orion crew capsule with escape system at the topNASA’s Orion crew capsule is getting more and more a reality. I just received an interesting HSFNEWS news release telling that test of the escape system will happen soon.

Report #H07-252

GROUNDBREAKING SIGNALS START OF NASA’S CONSTELLATION FLIGHT TESTS

LAS CRUCES, N.M. – With less than a year until flight tests of NASA’s Constellation Program, work is under way on a launch pad that will host the first of those tests. Workers broke ground on a pad where the agency will test a launch abort system for the new Orion spacecraft at the U.S. Army’s White Sands Missile Range near Las Cruces, N.M.

Orion’s launch abort system will carry astronauts to safety in the event of a problem on the launch pad or during the spacecraft’s climb to orbit. The first of five tests of the system, known as Pad Abort 1 or PA-1, is scheduled for fall 2008. Data from the series will help engineers refine the design of the launch abort system.

“Flight tests are where the rubber meets the road. These tests will help validate our designs or correct any flaws,” said Skip Hatfield, Orion Project Manager at NASA’s Johnson Space Center, Houston. “The goal here is simple: to provide our astronauts a route to safety should anything go wrong at a launch.”

The first launch abort test will include a mock-up of the Orion capsule on the pad. An abort motor will fire for two seconds, sending the boilerplate crew module to an altitude of one mile. Three 116-foot diameter parachutes will deploy to slow the mock crew capsule for landing.

Constellation is developing the Orion spacecraft to send astronauts to the International Space Station and to the moon. Orion will be launched atop an Ares I rocket. The program is also developing a heavy-lift rocket, Ares V, to enable cargo missions to the moon. NASA plans to set up a lunar outpost by 2020, where astronauts will prepare for possible future missions to Mars and other destinations in the solar system.

Video of the groundbreaking ceremony will be available Thursday on NASA Television Video File. For NASA TV downlink, schedule and streaming video information, visit:

http://www.nasa.gov/ntv

To learn more about NASA’s space exploration plans, visit:

www.nasa.gov/exploration

syslog GSS-API usage notes

I copy over some usage notes from Peter Vrabec’s intial announcement of the patch:

It adds a new commandline option ‘-g’ to listen for a connection wrapped with gss-api and few new configuration directives:

for server:

$gsslistenservicename <service name>

for client:

$gssforwardservicename <service name>
$gssmode <encryption|integrity|none>

With gssmode set to “encryption” or “integrity” all tcp selectors will be forwarding messages via gss-api.

That’s probably useful while I am getting up some real documentation.

GSS-API for Rsyslog

I just reviewed and integrated a patch from varmojfekoj into rsyslog – it provided GSS-API support. I have to admit that I have not yet fully understood what it does from a user’s point of view. But I begin to have the feeling that this patch will probably be the most important addition to rsyslog in the later half of this year.

I also have not yet evaluated how this patch relates to the syslog-sec IETF syslog security effort, namely syslog-transport-tls. I guess they are related and the patch probably not only provided non-standard functionality but may even make it harder to implement the standard. HOWEVER, if we look at how slow moving that IETF WG is, I do not bother about any compliance problems. They can be dealt with later. What I find much more important is that we have a real-world answer to real-world security question and we do have this now. So what could be more important? ;)

I keep you updated on the progress.