Posted: October 7th, 2011 | Author: rthomson | Filed under: Sysadmin | Tags: datacenter, neural emesis, rant, server | No Comments »
“The primary motivation for the decentralized model is to give the individual departments better or more customized service through having a stronger relationship with the SAs and more control over the work that they do. The primary motivation for centralizing system administration is to control costs through tracking costs centrally and then reducing them by eliminating redundancy and taking advantage of economies of scale”
– The Practice of System and Network Administration, Thomas A. Limoncelli and Christine Hogan.
Bingo. But can there be a third hybrid model?
I currently represent the decentralized model and I must agree with these two fine authors that the benefit of my close working relationship with the individual department/group is that the service provided is highly customized and focused. The central IT department(s) are understandably focused on large-scale issues (“Infrastructure”, “Communications”, “Collaboration”, “Applications”) and as such do not always represent the most ideal channel for delivery of IT services to the various research groups and departments on campus, often with more nuanced, specialized and micro-level issues.
One of my developing long-term goals is to (warning: business jargon) “bridge the gap” between the focused local support that I currently represent and the value proposition(s) of centralized IT services. I’m not yet entirely certain of how to accomplish this but I am certain that there is a way to improve the delivery of IT services to researchers across all our campuses and I want to be involved.
Does such an approach warrant the definition of a third hybrid model or is this so-called bridging of the gap already encapsulated in the model of centralized vs. decentralized?
Some of the challenges I face specifically as a “standalone” decentralized sysadmin on campus are:
- Dealing with all IT needs from desktop support to infrastructure development to data security
- Developing and maintaining vendor contacts and relationships
- No immediate peers in our environment to bounce specific ideas around with
- Weak purchasing power and negotiation leverage
- Duplication of effort
- Career progression is potentially limited
- All too easy to develop a “King of the Castle” attitude
- Complacency
Some of the concerns I hear about when introducing researchers to the idea of centralized IT support:
- General lack of trust/faith in the centralized IT department
- Perceived lack of personal attention and focus (turn around times, site knowledge, etc.)
- Perceived lack of “control” over their environment (and data!) under the centralized model
- Charge-back models for IT services are viewed as grant-unfriendly
- Physical hardware ownership appears to remain important for many researchers
Of course, this is but a snapshot of the challenges I face and the concerns I’ve been hearing but they do serve as decent examples. It must also be noted that I am seeing great progress is many of these areas already because there are very bright people here already working on these challenges. My interest in this field is absolutely not unique.
For the immediate future, I’m focusing on improving my collaborations and communication with centralized IT services by helping them out where I can and leaning on them more often for our localized problems. My hope is that by constantly forging a closer working relationship will increasingly expose me (and in turn, our group) to the benefits of the centralized IT model while providing the central IT group with greater insight into our environment and how we work.
The next steps are still a mystery to me but I’m keeping my eyes open for new opportunities to bring better IT to research.
Posted: August 24th, 2011 | Author: rthomson | Filed under: Sysadmin | Tags: freeipa, linux, redhat, samba, server, software | 1 Comment »
FreeIPA makes a pretty excellent backend for Samba 3. While all the information one needs to set this up is available online, I wasn’t able to find it all in one location so I’ve decided to try my best at filling that gap here on techslaves.org. Hopefully this short guide will aid those trying to piece together the various parts necessary to integrate FreeIPA v2 and Samba 3, at least until FreeIPA v3 where there is talk of enabling Samba integration with a simple command line argument to the “ipa-server-install” script.
Not for Domains
It’s important to keep in mind that these instructions are not for a integrating FreeIPA with a Samba domain controller but merely a Samba file server. My understanding is that FreeIPA will never conveniently/properly support the necessary bits to make it a suitable backend for a Samba 3 PDC. I believe FreeIPA will eventually look towards Samba 4 integration (using Domain trusts) for this kind of integration but don’t quote me on that. Either way, these instructions are not for Samba domain controllers, just Samba file servers.
The Assumptions
There are some basic assumptions that these instructions make.
- FreeIPA is installed and functional
- You have a general idea of how to use LDAP command line tools
- If you have a nice GUI LDAP browser, you can use it to apply the example LDIFs and edit the tree instead of the ldap CLI tools
- The LDAP commands are executed on the FreeIPA server
- Samba and FreeIPA are installed on the same server (although it shouldn’t be difficult to use TLS encryption with separate servers)
- Your LDAP suffix is “dc=domain,dc=tld”
- You know the difference between the “admin” account and the directory manager and their passwords
The Goods
Let’s not beat around the bush any further.
1. Determine your Samba server SID by executing the following command while smbd is running and jot it down:
root@ipaserver:~
# net getlocalsid
SID for IPASERVER domain is: S-1-5-21-3180075094-3458813485-3821849995
2. With the “admin” kerberos ticket, add two attributes to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” that tell FreeIPA to setup each account as a Samba account and each group as a Samba group:
ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: modify
add: ipaUserObjectClasses
ipaUserObjectClasses: sambaSAMAccount
-
add: ipaGroupObjectClasses
ipaGroupObjectClasses: sambaGroupMapping
EOF
3. With the directory manager password and the Samba SID you jotted down from above, create an instance of the 389 DS DNA plugin that will automatically generate SIDs for your users and groups which are necessary for use with Samba:
ldapadd -x -D "cn=Directory Manager" -W <<EOF
dn: cn=SambaGroupSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
dnatype: sambaSID
dnaprefix: S-1-5-21-3180075094-3458813485-3821849995-
dnainterval: 1
dnamagicregen: assign
dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))
dnascope: dc=domain,dc=tld
cn: SambaSid
dnanextvalue: 15277
EOF
The thing to note here is that the “dnaprefix” is set to the SID your jotted down… PLUS a hyphen (“-”) appended to the end!
4. Now we have to start modifying the FreeIPA API, CLI and WebUI to allow us to specify the “sambaGroupType” attribute at group creation time. We have to set “sambaGroupType” because it is a required attribute for the objectClass “sambaGroupMapping” which we are automatically adding to every group with the “ipaGroupObjectClasses” setting from earlier.
Although the value is going to be “4″ for every conceivable case in this non-domain configuration, I was not able to figure out how to make the DNA plugin insert static values like it can set incrementing values so I decided to allow setting it through the CLI and WebUS with defaults enabled instead. If anyone knows how to setup 389 to automatically add an attribute with a static value upon DN creation of DNs with specific objectClasses, please tell me.
There are a few steps required to make this CLI/UI stuff happen but the FreeIPA developers have actually made this quite simple.
The rule is: Extend the FreeIPA schema first, then the CLI, then the WebUI.
4.1. Extend the FreeIPA schema with a custom field by adding the attribute “ipaCustomFields” with a value of “Samba Group Type,sambagrouptype,true” to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” with an “admin” kerberos ticket:
ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: add
add: ipaCustomFields
ipaCustomFields: "Samba Group Type,sambagrouptype,true"
EOF
As there can only be one “ipaCustomFields” attribute, if you have multiple custom fields you need to separate each definition with a “$” like so: “Samba Group Type,sambagrouptype,true$Description,attrname,isrequiredboolean”.
4.2. Extend the CLI for groups by editing the python file “/…/site-packages/ipalib/plugins/group.py” to define the custom field and specify a default if not implicitly defined (diff):
--- group.py.orig 2011-08-15 14:59:48.570715207 -0700
+++ group.py 2011-08-16 12:43:43.493236507 -0700
@@ -118,6 +118,13 @@
label=_('GID'),
doc=_('GID (use this option to set it manually)'),
),
+ Int('sambagrouptype',
+ cli_name='sgt',
+ label=_('Samba Group Type'),
+ doc=_('Samba Group Type (default is 4)'),
+ default=4,
+ autofill=True,
+ ),
)
api.register(group)
Important: Restart “httpd” at this point!
4.3. Test the CLI. With an “admin” (or equivalent priv) kerberos ticket, try creating a new group:
account@ipaserver:~
$ ipa group-add testgrp --desc="Testing the group.py CLI mods"
---------------------
Added group "testgrp"
---------------------
Group name: testgrp
Description: Testing the group.py CLI mods
GID: 1234500010
Samba Group Type: 4
4.4 With the CLI functioning properly, we can move on to extending the WebUI. To extend the WebUI for group attributes, edit “/usr/share/ipa/ui/group.js” like so (diff):
--- group.js.orig 2011-08-15 10:01:28.515209121 -0700
+++ group.js 2011-08-16 13:52:59.587352034 -0700
@@ -34,6 +34,7 @@
column({name: 'cn'}).
column({name: 'gidnumber'}).
column({name: 'description'}).
+ column({name: 'sambagrouptype'}).
dialog(
IPA.add_dialog({
'name': 'add',
@@ -41,6 +42,7 @@
}).
field(IPA.text_widget({name: 'cn', undo: false})).
field(IPA.text_widget({name: 'description', undo: false})).
+ field(IPA.select_widget({name: 'sambagrouptype', undo: false, options: [{label: 'Local', value: 4}, {label: 'Domain', value: 2}]})).
field(IPA.checkbox_widget({
name: 'posix',
label: IPA.messages.objects.group.posix,
@@ -56,6 +58,7 @@
}).
input({name: 'cn' }).
input({name: 'description'}).
+ input({name: 'sambagrouptype'}).
input({name: 'gidnumber' }))).
facet(
IPA.group_member_user_facet({
And then these the WebUI to ensure that you can both see the attribute in the group list, but also add it via the select widget added to the new/edit group dialog.
That should be it. Questions, comments, suggestions, correction and more… all are welcome!
Posted: March 8th, 2011 | Author: rthomson | Filed under: Sysadmin | Tags: crux ppc, cruxppc, debian, distribution, distro, gentoo, ibm, linux, p505, p505 express, ppc, ppc64, pseries, server | 2 Comments »
We (work) have two IBM p505 Express Servers.
Right now one machine is running an old way out of support RHEL4 installation and the other is on Fedora 12, which is no longer supported by the Fedora Project. Paid support/subscription is not a consideration yet for this project, but I do want to run a modern Linux distribution for the associated modern application software and maintenance.
I basically need to move these servers to something free and supportable. I’m finding out that there aren’t a lot of options in PPC Linux as when I was last interested in this architecture. It’s pretty much just:
I realize there is RHEL and SuSE Enterprise for PPC64 but those are subscription products without free binaries available. I’m not prepared to build an RPM-based distro from source at this point so I need something with binaries or something where building from source is highly automated and integrated, such as Gentoo. Digression…
The question is which of these distros do I go with? To answer the question I suppose I need to define the roles.
These two pSeries servers a redundant pair running LDAP/Auth Service, NTP, DNS and DHCP. The load is low but I want a solid modern software platform on both these servers from now until they are replaced with in the future (which is likely to be integration into a centralized architecture).
With that said, and with my familiarity level of these distros, I would first lean towards Debian and then to Gentoo and finally to CRUX PPC.
Debian is a binary distribution, which is nice for maintaining a server. Debian is more familiar to me. What are the arguments for Gentoo or CRUX PPC?
Agree or Disagree?
Posted: October 5th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: ldap openldap, linux, server, software | 1 Comment »
Is it just me or are there no LDAP user management tools that support User Private Groups (UPG)?
I’m well aware of the FreeIPA project and that project does in fact support UPG, probably because it’s a RedHat project but I’ve determined that FreeIPA is too comprehensive for my needs. Despite Kerberos being the “right” solution in every sense of the term, I’d rather have the simplicity of binding to the LDAP server for authentication, even though I know that using LDAP as an authentication service is “wrong”.
My question, loyalty challenged readers, is: Are there any LDAP user management tools out there that support UPG?
Let me start the list:
- LAM – NO
- phpLDAPadmin – NO
- Luma – NO
- LAT – NO
- Gosa – NO
- smbldap-tools – Maybe?
Not to bash any of those tools, but I’ve decided to start writing my own simple “useradd” script for now because the workflow for creating a user with the UPG scheme with any of these tools is an annoying multi-step process. While my solution is site-specific and non-comprehensive, it just exactly the job I need done, done. And fast. I used perl and Net::LDAP, among other modules. Once I figured out if I want to it keep it on the console or move it to the web, I’ll post the results… even if it won’t be useful to anyone as-is.
