Posted: October 14th, 2010 | Author: rthomson | Filed under: Updates | Tags: code, GUI, ldap, python, software, wxPython, wxWidgets | No Comments »
Let me preface by saying that I’m not a programmer nor software developer nor anything of the sorts. I’m a sysadmin with scripting skills to solve automation problems, for the most part. I took all the C++ classes in High School but I never pursued software development as a serious academic interest or career. I know “about” software development and it’s practices but I don’t feel that I have any particularly interesting skills in the field.
Now that I want to write a site-specific GUI-based LDAP management tool as referenced in a previous post, I’m jumping back into software development a little bit. I’ve decided to use wxPython for a few reasons. We already use it within our group, we have in-house expertise in the form of an actual developer and the GUI-builder tools seem to work best with wxPython (wxGlade was producing bad wxPerl code, go figure).
Let me also say that I’ve never been a big python guy. I’m really a perl kind of dude, so this learning a new object oriented API while learning python at the same time is a challenge… but I’m making progress! Basically, wxPython seriously kicked my ass for about 3 days but now I’m gaining speed and things are moving faster than I expected. Python and wxPython are starting to make more sense and behave.
So far I have a frame with menubar, statusbar and a three-tabbed notebook with a grid on each tab of the notebook. The program is able to connect to an LDAP server (with TLS) and query the directory for all the users, groups and autofs information and then display that information in the grid… and that’s about it so far. I need to build in new user, group and autofs functionality as well as basic editing of existing entries (in place editing with wx.Grid looks really nice but I haven’t tried it yet!).
Although my ass has been kicked for the last few days, I’m actually feeling pretty optimistic about it now.
Hopefully I can share the kludge code at some point, though it will never be easily transportable to different environments since I’m not building this to be the end-all-be-all LDAP user/group/autofs management tool, just one tailored for our environment.
Posted: May 18th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: cfengine, code, denyhosts, linux, security, server, snippet, software | No Comments »
I’ve recently begun looking into configuration management with cfengine 3. I’ve ignored this growing sub-field of system administration for too long and I just can’t ignore it anymore. After spending quite some time researching the philosophies, methods and different tools out there, I settled on starting out with cfengine 3. There’s no special reason that I chose cfengine instead of puppet, bcfg2, chef or AutomateIT. I haven’t used any of these tools and thus I cannot pass judgement on them or their methods. All these projects seem to have intelligent and highly motivated people behind them. I simply gravitated towards cfengine because of its strong academic background and the fact that version 3 now represents the most recent and modern research in the field by Mark Burgess et. al.
As part of my learning experience with cfengine, I’ve decided to start posting some of the code that I’ve begun developing in the hopes that by writing about it, I can learn better, faster and maybe even receive some helpful comments from readers along the way. Beware, I’m a cfengine newbie and so what I post here should NOT be copy and pasted into your environment unless you’re ok with the potential of wildly breaking things!
The first snippet of code I want to discuss is related to managing our DenyHosts configuration. As part of our “security policy”, I would like to ensure that every RedHat/CentOS system is running a properly configured DenyHosts instance. Here is what I’ve come up with so far.
[ Read More ]»
Posted: May 7th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: code, linux, security, server, software, vendor | No Comments »
I recently decided that it’s about time to setup consistent, explicit and tight firewall policy across our Linux (mostly RHEL/CentOS) servers. One of the initial issues I faced was NFS. NFS implementations are very well known to make use of the portmapper and dynamically assigned port for rpc.mountd and because of this dynamic assignment, firewalling NFS can be challenging.
Luckily, RedHat’s /etc/sysconfig/nfs configuration file read by various “nfs”, “nfslock” and RPC services init scripts provides an easy means of locking down specific ports for all the NFS-related services so that one doesn’t have to work around the dynamic port assignment problem when it comes to firewalling.
[ Read More ]»
Posted: April 23rd, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: acl, code, linux, shell, unix | 3 Comments »
I’ve recently come across a situation where the inherent design of POSIX ACLs has left me scratching my head for a solution to the problem of setting up a “project” or “group share” directory on Linux. The problem is as follows: We have several different projects or groups that desire a directory where any and every file created, copied or moved to said directory will become owned by a particular group and have group read/write permissions set automatically.
Most of the problem is solved through age-old UNIX techniques. For group ownership, all we need to do is setup the top-level directory to be owned by the “project” or “group share” group and setgid the directory:
$ mkdir project1
$ chown .projgroup project1
$ chmod g+s project1
This effectively forces every file created, moved or copied into the “project1″ directory to be owned by group “projgroup”. So far, so good. The difficulties begin when we attempt to use default ACLs to enforce the permissions of any files created, moved or copied into the directory.
The POSIX ACL standard defines “default” ACLs which can be applied to a directory, which are in turn inherited by newly created/copied/moved child files and directories. While the default ACLs are inherited properly, the ACL mask when applied to files copied into the group share directory WITHOUT previous group write set prevents the files from being group writable!
$ getfacl project1
# file: project1
# owner: root
# group: projgroup
user::rwx
group::rwx
other::r--
default:user::rw-
default:group::rw-
default:group:projgroup:rw-
default:mask::rwx
default:other::r--
So far so good, right?
$ ls -alh test
-rw-r--r-- 1 user1 user 0 Apr 23 15:10 test
$ cp test project1
$ ls -alh project1/test
-rw-r--r--+ 1 user1 projgroup 0 Apr 23 15:10 project1/test
What the… ?!?! No group write? Noooooo!
$ getfacl project1
# file: project1/test
# owner: user1
# group: projgroup
user::rw-
group::rw- #effective:r--
group:projgroup:rw- #effective:r--
mask::r--
other::r--
And so we have the great POSIX ACL mask problem, which is by design in fact. Still looking for a complete solution that doesn’t involve global trying to force a specific umask on every account… It would be nice if I could ensure that every file had group write set before it was copied into the group share directory but alas, I cannot. Telling users to manually check and change permissions is also a pain. Cron jobs to change group write recursively is also ugly. Please, someone provide me with the solution.
Posted: March 30th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: code, perl | No Comments »
Here is a little perl script I wrote some time back for converting a text file’s contents from lines to columns.
I’d like to present this script and then psuedo-challenge other visitors of this site to write a more efficient algorithm in the language of their choice. Unfortunately, any way (that I know of) for measuring the efficiency of two or more algorithms across different languages is going to be skewed due to differences in efficiency of compilers, interpreters and what not.
[ Read More ]»