From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-sysadm/2010-November/000592.html | 146 ++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 zarb-ml/mageia-sysadm/2010-November/000592.html (limited to 'zarb-ml/mageia-sysadm/2010-November/000592.html') diff --git a/zarb-ml/mageia-sysadm/2010-November/000592.html b/zarb-ml/mageia-sysadm/2010-November/000592.html new file mode 100644 index 000000000..6391707f4 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000592.html @@ -0,0 +1,146 @@ + + + + [Mageia-sysadm] Main tasks for the next days + + + + + + + + + +

[Mageia-sysadm] Main tasks for the next days

+ Buchan Milne + bgmilne at multilinks.com +
+ Wed Nov 17 12:18:25 CET 2010 +

+
+ +
On Tuesday, 16 November 2010 00:55:15 Michael Scherer wrote:
+> Le mardi 16 novembre 2010 à 00:12 +0100, nicolas vigier a écrit :
+> > Hello,
+> > 
+> > As was decided in tonight IRC meeting, the priority tasks for sysadmin in
+> > 
+> > the next days will be :
+> >  * the configuration of pam_ldap, nss_ldap, and everything needed to
+> >  
+> >    allow commits from LDAP accounts on SVN
+
+I have created some "host" accounts in LDAP, so far for alamut and valstar, to 
+test that they have sufficient access for nss_ldap. I might need to open up 
+read access to member attributes of groups (at present, all users have search 
+access to member attribute, but not read, so you can determine if a user is a 
+member of a group, but not see all the members, this is probably sufficient 
+for assigning groups on login, but not sufficient for 'groups foo' or 'id foo' 
+to work as expected).
+
+However, we probably need to decide on a time and host to test this on, as 
+mistakes etc. with authentication configuration can be inconvenient.
+
+> >  
+> >  * the configuration of forums with LDAP accounts (to be finished)
+> 
+> A first step would be to make sure that people in charge of forum read
+> this list and are subscribed to it. And another step would be to know
+> what they do, since I am spammed every day by the cron job who update of
+> urpmi who is bounced to root at zarb alias, as the server is
+> misconfigurated ( ie, it send mail to a alias that do not exist ).
+
+Maybe these issues should be discussed with the web team today.
+
+> >  * the configuration of sympa mailing lists server using LDAP for users
+> >  
+> >    authentication
+> 
+> We didn't really discussed how and what we will use ldap and sympa for,
+> and that we setup without thinking first about the full picture.
+> 
+> Ie, if sympa use ldap for authentication, does that mean that people
+> will be forced to use identity to subscribe ?
+
+I was aiming for all users having *one* account, with one username and 
+password, from when they start (e.g. want to post on forum, subscribe to 
+mailing list) until they are on the sysadmin team, maintained on identity.
+
+I am not very familiar with sympa, but I was expecting that users would be 
+able to log in to the sympa web interface with their LDAP account, and 
+subscribe/unsubscribe there. Whether that subscription is maintained in LDAP 
+is IMHO not as relevant.
+
+In the case of "teams" that have corresponding groups in LDAP, it may make 
+sense to have corresponding automatic mailing lists (as it would reduce some 
+overhead).
+
+identity is used to manage the users identity information, and should be 
+authoritative for that, but I don't expect to have to add features for 
+administering every applications settings for a user (e.g. signature for 
+forum, digest settings for mailing lists etc.). Where there is more identity-
+related information that we may want to leverage in more than one application 
+(e.g. avatar or photo or mugshot or whatever), we can look at that.
+
+> How would it goes for moderation ?
+
+Nothing to do with LDAP (except possibly authenticating moderator on sympa web 
+interace).
+
+> How would they do for subscription ?
+
+Authenticate user against LDAP on login to sympa web interface, nothing more.
+
+dmorgan asked me to add some ACLs allowing addition of some data for mailing 
+lists, but as far as I could tell, it looked like aliases for mailing list 
+administration (e.g. xxx-subscribe at lists. etc.). Now, AFAICT, this is not 
+strictly required for sympa operation ... it all depends on the MTA setup. If 
+aliases are going to be in LDAP, then IMHO the existing 'MTA Admins' system 
+group should be used, and I will give it write access to a tree (e.g. ou=mail 
+or so) for aliases not related to users.
+
+But, I need to know what access is required for the non-user-authentication 
+features of sympa for which we would like to use LDAP as backend, so I can 
+assign sympa user to correct groups and check ACLs.
+
+Regards,
+Buchan
+
+ + + + + + + +
+

+ +
+More information about the Mageia-sysadm +mailing list
+ -- cgit v1.2.1