One distinction I'd make regarding Paul's feedback would be for systems with mixed accounts. If a system primarily uses LDAP, for example, but perhaps I only want to look for expired local accounts (since most likely expired LDAP accounts would be handled differently), then I'd want to be able to specify that to such an expirdeaccounts() function.
Justin -----Original Message----- From: Paul Krizak [mailto:paul.kri...@amd.com] Sent: Monday, November 30, 2009 8:28 AM To: Justin Lloyd Cc: Mark Burgess; help-cfengine@cfengine.org Subject: Re: Deleting expired user accounts This sounds like a useful feature. I actually just finished implementing some code (unfortunately via a shellcommand) to clean up expired users' processes on our systems. Having a native expiredusers() function would be very useful. My feedback would be to ensure that the function uses the OS's native NSS bits. For example in our case, we use NIS, so looking directly at /etc/passwd and /etc/shadow would be useless. Paul Krizak 7171 Southwest Pkwy MS B200.3A Senior Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Silicon Design Division Fax: (512) 602-0468 On 11/23/09 15:44, Justin Lloyd wrote: > Hi Mark, > > Thanks for your thoughts on this. As for the policy being brutal, it's > actually on an FTP server and the script cleans up expired temporary > accounts. :) > > However, I've been thinking about this since last Thursday evening after > I left work. I remembered that the script is sometimes (rarely) run > manually with slightly different options from the cron job if we need to > free up additional disk space quickly. It may be more valuable in this > case for us to keep the script and just run it like a typical cron job > from within the cfengine policy. Another approach may be to continue > with implementing this in Cfengine, perhaps as I've illustrated in the > mockup, but we could potentially "run the script" by running cf-agent > manually, perhaps in a wrapper script. I'll have to think on that and > whether it would just be defeating the purpose of getting rid of the > original shell script in the first place. :) > > As for your thought on a built-in function, that's an interesting > consideration, but I'd think you would have concerns about adding such > miscellaneous functions and the possible precedents that could set. Here > are some random thoughts, however, on the arguments for this function or > perhaps a related or more generic one: > > * username regex? pcre example: /^g[a-z0-9]{15}$/ (matches our > aforementioned temporary accounts) > * string indicating whether active or expired accounts should be > returned (e.g. expired, active, all/any) > * string indicating whether accounts whose passwords have recently been > changed should be returned > - and maybe an non-negative integer field for days since the change, > or use the shadow file's warning field > * signed integer of (time units) since/until accounts expire, for > example... > - return all accounts that expired within the last 7 days > - active accounts that will expire within the next 3 days > * string indicating whether accounts with locked passwords should be > returned > > Whether these and/or any other ideas could be rolled up into a generic > "local accounts"-type of function, rather than creating multiple ones, > like expired_accounts(), locked_accounts(), etc., is up to you. :) > > So a more generic example that meets my original requirement might be > something like this (though we do "more than 1 day ago", passing "-d -1" > to our current shell script, the "find" command basically does the same > as this example): > > # > # return the list of usernames of temporary ftp accounts that expired at > least 2 days ago > # > "expired_temp_ftp_accounts" slist => local_accounts("^g[a-z0-9]{15}$", > "expired", "-2"); > > Just my $.02. > > Thanks, > Justin > > > -----Original Message----- > From: Mark Burgess [mailto:mark.burg...@iu.hio.no] > Sent: Thursday, November 19, 2009 11:16 PM > To: Justin Lloyd > Cc: help-cfengine@cfengine.org > Subject: Re: Deleting expired user accounts > > > Hi Justin, > > I don't see anything wrong with your approach, although the policy > itself is quite brutal > ;-) There will eventually be some kind of arithmetic for cfengine, but > the priority is low > compared to things like virtualization support that we are working on > for Nova. > > In this case though, I would think that an inbuilt function would be the > way to go that > could replace your perl script. something like > > .... slist => expiredaccounts(some kind of threshold, etc...) > > So what would the arguments be, to make this adaptable to all > cases/OSes? > > > Justin Lloyd wrote: >> Hi all, >> >> I'm still in learning mode (haven't implemented cfengine yet) but I'm >> thinking about how to reimplement certain existing functions in our >> environment in the most cfengine-like way. >> >> Currently we have a perl script that runs daily on a server, deleting >> any expired accounts (anywhere from zero to sometimes well over 100) >> that have a certain gecos field in /etc/passwd. The script analyzes >> accounts in /etc/shadow and determines which ones' passwords expired >> more than 1 day ago and it deletes those accounts using userdel. >> >> I can't see a way to have cfengine determine expired accounts on its > own >> (mainly due to its lack of native arithmetic capability), so here's a >> mockup of a similar approach, where the script would simply output the >> list of usernames whose accounts meet the criteria for deletion. >> >> bundle agent test { >> vars: >> servername.Hr00.Min00_05:: >> "expired_accounts" slist => { >> execresults("/usr/local/bin/list_expired_accounts", >> "noshell"); >> }; >> >> commands: >> servername.Hr00.Min00_05:: >> "/usr/sbin/userdel -r $(expired_accounts)"; >> } >> >> Is there an approach I could take that would eliminate the need for an >> external script, having cfengine determine the expired accounts >> natively, or does this seem like the cleanest, most cfengine-like way > of >> handling this requirement? To be honest, I'm not even seeing a huge >> value in splitting the function in two, but it was an interesting >> problem to consider. >> >> Thanks, >> Justin >> >> >> This electronic communication and any attachments may contain > confidential and proprietary >> information of DigitalGlobe, Inc. If you are not the intended > recipient, or an agent or employee >> responsible for delivering this communication to the intended > recipient, or if you have received >> this communication in error, please do not print, copy, retransmit, > disseminate or >> otherwise use the information. Please indicate to the sender that you > have received this >> communication in error, and delete the copy you received. DigitalGlobe > reserves the >> right to monitor any electronic communication sent or received by its > employees, agents >> or representatives. >> >> _______________________________________________ >> Help-cfengine mailing list >> Help-cfengine@cfengine.org >> https://cfengine.org/mailman/listinfo/help-cfengine > This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
