blog'o thnet

To content | To menu | To search

Monday 14 October 2013

Move Away From The Press Review

Well, a little bit of history about the press revue. Initially, the press review was born as a request from one of my customer, a little more than four years ago. A this time, this revue was oriented towards its locally used technology only, and was commented and discussed to sum things up appropriately according to its own needs.

Since then, this revue was finally regularly published on this blog--some months after I leaved this customer in fact--, but it now takes me some time to collect and format, and was not really discussed anymore: it's just a bunch of (I hope ;-)) interesting links, but without much of value as it stands now. More, that information which are asynchronous by nature are not well served when published once a month, when interesting news came at the beginning of a month and is only released four weeks later through the press revue.

So, I decided to push these links more synchronously through my Twitter account, which feed this need more appropriately I think. This way the information will flow more regularly, and no need to wait for a bunch of them late each month. Please Follow @_thnet to subscribe to the new form of the press review :)

Last, I just want to say I will try my best to resurrect the old purpose of this blog which is more about writing technical contents, better served using this kind of media.

I hope these changes will fit your needs. Please let me know if you see any problem with this move. Thank you.

Wednesday 25 February 2009

Problem Querying ru. Name Servers

In a previous position, I encounter a rather strange problem I would like to share here. It has to do with DNS resolution. From the internal network of a company it was not possible to get the IP address of the host name.

We determined that the name servers which manage the domain are and In the same time, we saw that for the domain name, the managing name servers are and Interestingly, it was possible to resolve using, but not from More, we noted that the reverse resolution for the name servers and are not correct, translated to and, respectively. So, it is worth to mention that nothing was wrong when querying the name server

# host -t a has address
# host -t a has address
# host -t ptr domain name pointer
# host -t ptr domain name pointer

The error from the DNS query seems to be related to an incomplete answer from the server (the truncated flag was set to 1 in the network trace) when the query is made over UDP. In this case, an automatic fallback over TCP must be used, certainly prohibited from the company's network security policy. This may say that the answer is larger than 512 bytes long, too. So, we tried to advertise different sizes of the UDP message buffer, but without being confident that this message went through network devices properly. Nonetheless it would seem curious to get an answer larger that 120 bytes long.

Last, we can note that the complexity of the network layout (DMZ, firewalls, NAT, etc.) may badly interact and hamper DNS queries, at least in certain circumstances.

After more investigation from the network team, they decided to permit TCP DNS queries. And it worked. It worked letting the internal DNS servers doing their job themselves...

# dig +trace -t a
; <<>> DiG 9.3.4-P1 <<>> +trace
;; global options:  printcmd
.                       449798  IN   NS   L.ROOT-SERVERS.NET.
.                       449798  IN   NS   M.ROOT-SERVERS.NET.
.                       449798  IN   NS   A.ROOT-SERVERS.NET.
.                       449798  IN   NS   B.ROOT-SERVERS.NET.
.                       449798  IN   NS   C.ROOT-SERVERS.NET.
.                       449798  IN   NS   D.ROOT-SERVERS.NET.
.                       449798  IN   NS   E.ROOT-SERVERS.NET.
.                       449798  IN   NS   F.ROOT-SERVERS.NET.
.                       449798  IN   NS   G.ROOT-SERVERS.NET.
.                       449798  IN   NS   H.ROOT-SERVERS.NET.
.                       449798  IN   NS   I.ROOT-SERVERS.NET.
.                       449798  IN   NS   J.ROOT-SERVERS.NET.
.                       449798  IN   NS   K.ROOT-SERVERS.NET.
;; Received 512 bytes from in 0 ms

ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
;; Received 297 bytes from in 125 ms   345600  IN   NS   345600  IN   NS
;; Received 107 bytes from in 66 ms   86400   IN   A            86400   IN   NS            86400   IN   NS
;; Received 91 bytes from in 65 ms

... and it worked when querying directly the name servers responsible for the wanted domain:

# dig -t a
; <<>> DiG 9.3.4-P1 <<>> -t a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1530
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;             IN   A

;; ANSWER SECTION:      86400   IN   A

;; AUTHORITY SECTION:          86400   IN   NS          86400   IN   NS

;; Query time: 65 msec
;; WHEN: Tue Apr 15 21:05:12 2008
;; MSG SIZE  rcvd: 91

Note: The size of the answer is 91 bytes long, so nothing wrong from this side.

I think we will never know what was going wrong here, even if the heart of the problem seems related specifically only to the two same name servers.

Monday 5 January 2009

Quick Reference Guides For Network Technologies

I am always looking for some good IT cheat sheets, and for a lots of thing. Here is one of my favorite web site around network technologies. Interestingly, this site propose some regularly updated quick reference guides for the network, and are classified under the following categories (at the time of this writing):

  • Protocols
  • Applications
  • Reference
  • Syntax
  • Technologies
  • Miscellaneous

You can find them all at the Cheat Sheets Library section.

As the author wrote on his blog, if you notice an error or would like to see a new cheat sheet on a specific topic, don't hesitate and drop him a line.

Sunday 23 December 2007

Tuning Is Evil

Each month, I hear many coworkers or specific application management teams asking about putting some system tunings in place, even on very recent operating system releases. All the time. Most of these settings comes from the Internet, are found in forum posts, or articles related to a subsystem, or in technical publications. And some of them comes from third party software providers, or editors. A very, very few settings are proposed or recommended by system administrators, or by knowledgeable people in tuning area.

The problem is that, most of the time, these tunings are related to another release of the operating system, are not updated to keep current with the Best Of Practices for a given OS release, or simply are not well understood and not applicable without affecting (badly) current running environments. More, already present tunings are reported as-is on upgraded and fresh installed systems without more thinking, or without be assured these are always applicable (or obsolete) and what are the new defaults (if not dynamic). One of the most representative example today of this is the new System V IPC facilities found from the GA Solaris 10, and later, operating system, where some Oracle DBAs always ask SA team for shared memory settings as found on Solaris 8 systems.

Although extract from the Solaris Internals and Performance FAQ for ZFS, here is a great excerpt we all must read carefully and try to keep in mind when modifying default behavior of a system:

Tuning is evil and should not be general.

First, consider that the default values are set by the people who know most things about the effects of the tuning. If a better value exists, it would be the default. While alternative values might help a given workload, it could quite possibly degrade some other aspects of performance. Maybe, catastrophically so.

Over time, tuning recommendations might become stale at best or might lead to performance degradations. Customers are leery of changing a tuning that is in place and the net effect is a worse product than what it could be. Moreover, tuning enabled on a given system might spread to other systems, where it might not be warranted at all.

Monday 3 September 2007

Why Set a Local authorized_keys File in a NFS Shared Environment

Why set the authorized_keys file to a local pathname on large UNIX environments, especially when NFS shares are used for home directories? Because this can address security problems.

First, you must remember that this special SSH file stores the public key of a remote account, letting the owner to be able to log-in using asymmetric keys along with the corresponding passphrase instead of the more classical challenge with appropriate password mechanism. (This eventually enable for non-interactive login through the use of an SSH agent, latter.)

The default path for the authorized_keys file is in a subdirectory of the home directory. This means that when the home of a UNIX account is hosted on a NFS share, all servers available in the same domain as the NFS resource will have access to the very same authorized_keys file, thus opening a security flaw. This is a security concern since by allowing one account on one server, you open this account to all servers in the same domain.

So, the first benefit to store the authorized_keys file in a local name space on each server is to authorize one--and only one--access to a given machine. The direct drawback is that there will be as many authorized_keys file as the number of servers in a domain (if a SSH access is needed on all servers). A side effect is that the path, mode and owner of the directory which will host the authorized_keys file may be better managed and hardened than before (even if SSH already check those things for sane defaults). It is particularly of interest when managing thousands of servers in heterogeneous UNIX environment, when Solaris, AIX, Linux and HP-UX doesn't have the same ownership same system paths (such as /var, for example).

Saturday 12 May 2007

Do You Ever See Kids Wearing Toy Pagers Playing Sysadmin?

Well, this little question was in fact extracted from a recent blog entry by Paul Boutin (which defines itself as former systems administrator), and was the starting point for one of most interesting explanation from Ben Rockwood (still him :)), entitled Systems Administration as a Career: A Response. But if I personally find its words so interesting to me it is just because... they can be mine!

Basically, I can have say the same thing. In the past, I was not really good at school. Just enough to be able to go further. I got a personal computer relatively late at home. And I found really, really late that I was particularly interested by Systems. In fact, it was late at High School when I discovered both UNIX, and the feeling I clearly want to be a System Administrator. When other students get development projects, I asked for sysadmin oriented tasks, even if that was not planned in the school's program. And I got one (building a NIS environment based on Solaris servers deserving heterogeneous clients for the upcoming centralized UNIX infrastructure at school--using Solaris, HP-UX, and RedHat Linux).

Since then, I am a really passionate SA, and OSS believer. Today, I have more than six year playing this role, sometimes differently depending on customers needs and always evolving technologies. I can honestly say that I have permanently something new to learn, to try, to manage, or to build. More, I found myself to be in a great place to work with a lots of very nice--and sometimes totally nuts--guys, coming from very different backgrounds such as database and network engineers, managers, end-users, and pretty nice Internet IT-communities. So no, really, I didn't want to change my role anytime soon.

Last, if you are a staff manager for a system administrator right now, and think that its career evolution will obligatory go through project or team management, I urge you to read (or think more closely about) Ben's points one more time. Really. You will see that there are a lot of things which can be done in this area, as defined by benr.

Tuesday 8 May 2007

Best Practices in Installation Locations and Filesystem Hierarchies

As it is repeatedly discussed at work these days, I think it may worth mentioning there exists official locations to install bundled and unbundled packages, and well defined paths with a recommended purpose for most major players in UNIX and UNIX-like platforms such as Solaris, GNU/Linux and FreeBSD for example.

For Solaris (and OpenSolaris derived distributions), you can consult the Recommended Installation Locations for Solaris-compatible Software Components document from the Architecture Process and Tools community, along with the filesystem(5) manual page online, or on an installed system.

For a GNU/Linux environment, you can read both the Linux Standard Base and the Filesystem Hierarchy Standard recommendations.

Although the BSD are not so well-known as GNU/Linux, there are some very good and alive projects. More, the documentation available for each distributions are well written, and frequently updated. For these systems, and most notably FreeBSD and HP-UX systems, you can read the hier(7) manual page online, or on a live system.

As a side note, it is interesting to note that Ian Murdock (founder of the famous Debian GNU/Linux distribution, and just joining Sun to head up operating system platform strategy) is also the chair of the Linux Standard Base—while Sun is a member of the Linux Foundation (which host the LSB project). Maybe can we expect more standardization between these two major players in the future?

Tuesday 20 February 2007

Bad Online Reports on Windows Vista

Generally speaking, i am not really a big supporter of the Windows operating system. And most of the time, i wait to see and try something to get an opinion on it. But after seeing these three reports against recent Microsoft products (two on Windows Vista, one about Office 2007), i will certainly wait a little before even trying them, at least until the already planned (scheduled?) Service Pack 1 will be out (at least for Windows Vista).

I will not say much about it right now. Go reading the reports to get an idea of what frightened me in the first place, if you care:

Wednesday 10 January 2007

What is about... Virtualization

As we hear more and more things about server or data center virtualization nowadays, i found those those two articles to be very clear and interesting in explaining what is really involve behind this general term (virtualization).

The first one came from the developerWorks, whereas the second one is hosted on InformationWeek. Worth reading, really.

Thursday 4 January 2007

Learning Curves for Common Editors

Well, not a so very fresh nor a very interesting news, but i found this one funny. So, here it is:

Classical learning curves for some common editors

[Click on the picture to enlarge it.]

That's all... sorry.

- page 1 of 2