In the case of NIS etc, it is unclear whether it is possible to distinguish local from non-local as the system API makes this seamless/transparent. Well, we just have to study this when we find the time to consider this feature. Times are busy at the moment.
M Justin Lloyd wrote: > 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. > -- Mark Burgess ------------------------------------------------- Professor of Network and System Administration Oslo University College, Norway Personal Web: http://www.iu.hio.no/~mark Office Telf : +47 22453272 ------------------------------------------------- _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
