BOKS: Demystifying the user FLAGS field

2011-11-28 00:00:00

The BoKS database can be an interesting place to poke around, "mysterious" at times. For example, there's the enigmatic "FLAGS" field which resides in table 1, the user data table. Among the usual user information (name, host group, user class, password, GID, UID, etc) there's the "FLAGS" field which contains a numerical value. What this numerical value represents isn't clear to the untrained eye.

The "FLAGS" number is a decimal representation of a hexadecimal number, where each digit represents a number of flags. The value of each digit is determined by adding the values of the flags enabled for the user. You could compare it to Unix file permission values, like 750 or 644, there each digit is an addition of values 1, 2 and 4 (x, w and r).

Below you'll find a table of the flags that can be set for any given user account.

Max. valueF3E3

So for example, a value of 16386 equals a value of 0x4002, which means that the user is blocked and that BoKS is used to push his secondary group settings to the /etc/group file on each server.

kilala.nl tags: boks, sysadmin,

View or add comments (curr. 0)

Kendo omamori: charms for success and fighting spirit

2011-11-13 13:14:00

As I wrote before I bought a number of omamori when we were in Japan: amulets purchased at temples, for various purposes. For example: the one I bought for Marli is for a happy marriage, but there's plenty of other kinds. Good luck, aid in studies, good health, and plenty, plenty more. 

For my dojo's sensei and trainers I bought charms from the Hakozaki shrine, dedicated to Hachiman (a god of war and harvest). The ones I bought were for success in sports and seeing how Hachiman is protector of warriors I reckoned that was appropriate for kendoka and kenshi. It gladdens me that my teachers were happy with the token of appreciation and at least two of them now wear their omamori on the inside of their do. 

Now it's time to delve a little into the one I bought for myself. Bought at the Todaiji temple in Nara the origin is a bit of a contrast with my teachers' amulets. Hakozaki's shrine is shintoistic and dedicated to a god of war, while Todaiji is a buddhist temple; we all know the buddhist's take on violence. 

The creature, or person, depicted on my omari is Misshaku Kongō (密迹金剛), also called Agyō (阿形), one of the two Nio: wrathful and strong guardians of the Buddha. To quote Wikipedia:

"They are manifestations of the Bodhisattva Vajrapāṇi protector deity and are part of the Mahayana pantheon. According to Japanese tradition, they travelled with the historical Buddha to protect him. Within the generally pacifist traditions of Buddhism, stories of Niō guardians like Kongōrikishi justified the use of physical force to protect cherished values and beliefs against evil."

Agyō is a symbol of overt violent, as oppsoed to Ungyō who symbolizes latent strength. I reckon both make great deities for a bit of backup in kendo ^_^

Funnily enough, Flickr user GreenTea has the exact same omamori on his (or her?) do. The fine people at Miyako Kendogu also sell an omamori specifically for success in kendo, however Andy Fisher later told me this is not actually a blessed amulet, but instead "rather they are more of a novelty/souvenir type omamori". Of course the best places to buy omamori for budo sports is from the Katori and Kashima shrines, origin of budo. Those shrines were out of our way though, being east of Tokyo.

Interestingly I've learned that Amsterdam is home to Europe's only shinto shrine: Guji Holland Yamakage Shinto Shrine. At least there's a place close to home where we can safely (or at least in a traditional fashion) dispose of the omamori once they have served their purpose. 

kilala.nl tags: kendo, japan,

View or add comments (curr. 0)

Head cold? Screw it and let's fight!

2011-11-12 15:22:00

I've had a headcold all week, but decided to go to kendo practice anyway. I've been missing waaaaay too many classes, between our holiday and last week's absence. Aside from my kiai lacking severely (slimy vocal chords) it was a very educational class. 

Warmup was different, with a few less stretches than normal and no footwork or running at all. On the other hand, before that the group did longer kata practice than usual. We immediately went into kihon, doing kirikaeshi, various men strikes and kote-men sequences. After that the groups were split between bogu wearing folks and those without armor. My smaller group practiced maki waza (where you gain center by spinning your opponent's shinai in a loop) and hiki-men (where one strikes men on a backwards lunge).

Lessons to take away from today's class:

• On my upswing I go too far backwards. This impedes a swift blow because my shinai needs to travel further.
• It appears that, when striking, I don't come down the center line but from the right. 
• Both on fumikomi and hiki waza my timing is way off.
• My small men, as usual, is crap. 
• I need to start wearing my loaner bogu again. Even if I don't wear my helmet, the rest of the protection will allow people to practice strikes on me.

Class was finished with kakari geiko and uchikomi geiko: basically, each of us gets to attach the teacher as often and as fast as possible for X amount of time. 

Sadly I can't partake in tomorrow's "central training" where a few dozen kendoka from all over the Netherlands gather. Full armour is a requirement, so that's it for me. I hope to have my kendo glasses completed by january, so I can attend the next practice. Speaking of, you can see the glasses in the photograph.

kilala.nl tags: kendo, sports,

View or add comments (curr. 3)

BoKS: Successful login, but no logging

2011-11-04 00:00:00

Another fun one!

Case: Customer attempts to login, succeeds, then gets kicked from the system immediately with a session disconnect from the server. The BoKS transaction log however does not show any record of the login attempt.

Symptoms:

• Everybody except customer and his colleagues can login just fine. It's just one team who get the immediate disconnect.
• All normal logins show up in the BoKS log, as do all failed logins.
• Customer's failed logins, when entering a wrong password, do show up in the transaction log.

Troubleshooting:

• The BoKS client software works fine.
• Customer's account is fine, not locked, not broken.
• Customer's shell is valid and listed in /etc/shells.
• Customer's homedir is present and OK.
• Suggest that we proceed with deep BoKS debugging as outlined here.

Debugging:

• Started separate boks_sshd process on port 2222, with "-d -d -d" flags.
• Asked customer to connect and proceed as normal. Works as expected.
• BoKS_sshd trace information shows normal flow for:

1. Key exchange
2. User identification
3. User authentication
4. Session startup

Trace shows failure when forking shell for customer.

debug2: User child is on pid 495766
debug3: mm_request_receive entering
Failed to set process credentials
boks_sshd@server[9] :369851 in debug_log_printit: called. Failed to set process credentials151212
boks_sshd@server[9] :370000 in debug_log_printit: not in cache, add
boks_sshd@server[9] :370092 in addlog: add Failed to set process credentials151212 (head = 0x0)
boks_sshd@server[9] :370233 in addlog: head = 0x20332b28

Cause:

After doing a quick Google search, we concluded that customer's shell could not be forked due to a missing primary group on the server. Lo and behold! His primary group had not been pushed to the server by BoKS. This in turn was caused by corruption in AIX's local security files, which can be cleared up easily enough using usrck, pwdck and grpck.

This however does not explain why there was no transaction log entry for these logins. Because by all means this was a successful BoKS login: authentication and authorization had both gone through completely.

Hypothesis and additional test:

We reckon that the BoKS log system call for the "succesful login" message is only sent once a process has been forked, so on authentication+authorization+first fork. As opposed to on authentication+authorization as we would expect.

To test another case we switched a user's shell to a nonexistent one. When the user now logs in this -does- generate the "succesful login" message. This further muddles when the BoKS logging calls get done. FoxT is on the case and has confirmed the bug.

kilala.nl tags: boks, sysadmin,

View or add comments (curr. 0)