[LON-CAPA-admin] RE: Domain coordinator cannot log in after upgrade

Stuart Raeburn raeburn at msu.edu
Mon Oct 20 14:16:01 EDT 2008


In your original report you stated:
"The notable exception is that the domain coordinator account cannot log in."

I'm assuming that a user "bsudc" in the bsu domain was originally  
created when the first LON-CAPA library server was built for your  

If this is the case there should be a:
/home/httpd/lonUsers/bsu/b/s/u/bsudc directory

which contains: a file "passwd", with the contents:

If the passwd file contains anything else then this user will not be  
filesystem authenticated.

There should also be a roles.db file and a roles.hist. The roles.hist  
file is a plain text file which contains the role change history for  
the bsudc user.

A filesystem-authenticated user must have a Linux account on the  
server (check in /etc/passwd). For such a user you should be able to  
launch a shell on the server via ssh, and you could use the Linux  
command "passwd" to change the password for the user.  Whatever you  
set the password to using command line tools will also be the password  
you should enter via the LON-CAPA log-in page when logging in. If  
log-in via the LON-CAPA log-in page is failing for user bsudc, the  
/home/httpd/perl/logs/lonnet.log file should provide some indication  
why this is the case. (If /etc/passwd, /etc/group, /etc/shadow and  
/etc/gshadow were not preserved during the transition from Fedora 4 to  
CentOS 5.2, that would provide an explanation why log-in was failing).

As Stefan noted, if you have root privileges on the server, you can  
always create a new user with Domain Coordinator privileges, by running

perl make_domain_coordinator.pl [USERNAME] [DOMAIN]

located in loncapa-X.Y.Z/loncom/build (X.Y.Z is the version number).

However, this script will _not_ permit the creation of the DC if the  
username is already a Linux username on the server, or if the username  
is already in use as a LON-CAPA username in the domain.

You can assign Domain Coordinator privileges to an existing LON-CAPA  
account in your domain by running:

perl add_domain_coordinator_privilege.pl  [USERNAME:DOMAIN] [DCDOMAIN]

This script is also in loncapa-X.Y.Z/loncom/build.

Additional information about these scripts is available in the Domain  
Coordination Manual --  
http://msu.loncapa.org/adm/help/domain.manual.access.hlp included with  
the 2.7 release of LON-CAPA (see  
http://msu.loncapa.org/adm/help/Creating_Domain_Coordinators.hlp for  
the specific help item).

Although LON-CAPA continues to support filesystem authenticated users,  
LON-CAPA no longer provides a mechanism to assign this authentication  
type to new users, or to switch existing users to this authentication  
type, except by running the make_domain_coordinator.pl script (which  
can only create a new user).

As regards the manual procedure, step 9 in the perldoc (concerned with  
rolesmanip.pl) begins: "9. (as www). Run CVS: ..."   It would seem  
that the manual procedure was intended for users who have a CVS  
checkout of the LON-CAPA code. Certainly rolesmanip.pl is not included  
in the current LON-CAPA tarball release, and mostly like was not  
included in earlier releases.

The availability of add_domain_coordinator_privilege.pl, added in  
LON-CAPA version 2.5, makes rolesmanip.pl largely redundant for DC  
management (although a remove_domain_coordinator_privilege.pl script  
needs to be provided to completely eliminate the need for  
rolesmanip.pl). Furthermore, additional steps beyond those included in  
the perldoc for the "manual method" have been added to the  
make_domain_coordinator.pl script, since the perldoc was written in  
2002) which mean on a production server running either of the two  
scripts in loncom/build is much preferred to a manual method.

Stuart Raeburn

Quoting "Neubauer, Paul R." <pneubauer at bsu.edu>:

> Hi Stefan and anyone else who might be interested,
>> From: Stefan Bisitz <st.bisitz at fh-wolfenbuettel.de>
>> Hi Paul,
>> Some comments which hopefully help a bit:
>> - User accounts cannot be totally removed in the current LON-CAPA version.
>> Just make sure that nobody can login with the invalid user, e.g. set to
>> internally authenticated and set a random password.
> No problem. I've taken care of that.
>> - I guess you have consulted
>> http://www.loncapa.org/hardwareupgrade.html
>> ? However, from what you write I assume that you already successfully
>> passed the important steps.
> I did read that and incorporated it in my plan, in a slightly modified form.
>> - I slightly remember that I also had troubles to login with an
>> already existing DC account after having changed the server hardware,
>> the OS, the IP adress, ... and (nearly) the rest of the world... ;-)
> So this may be a more common problem.
>> I assume that "normal" users can login, just the DC (domain coordinator)
>> cannot. If so, my suggestions:
> That's correct. Normal users can log in but the DC could not.
>> a) Create a _new_ DC account with an so far unused user name for   
>> your domain.
>> Then log in with this new user and change the password for the   
>> _old_ DC account ("bsudc").
> I have now done that. I created "dcbsu" in addition to "bsudc"
>> b) It is possible that file system authentication is the origin
>> for the issues, but this is the method new DC accounts automatically
>> have. I think you don't need this kind of authentication. In this case,
>> switch the authentication method of your old DC account to
>> internally authenticated and enter a password. This should work.
> The new "dcbsu" account was created with filesystem authentication   
> and worked fine. I logged in to the web interface using that   
> account, and searched for my old domain coordinator "bsudc". I then   
> changed its authentication from filesystem to internal and now both   
> DCs work fine. :-)
> Of course, this still does not answer the question of why the old DC  
>  did not work following the OS upgrade or how to avoid it. (A very   
> important question for anyone who wants to do this in the future,   
> including possibly me.)
> The other obvious remaining question is whatever happened to   
> rolesmanip.pl? The internal documentation in   
> /root/loncapa-2.7.1/loncom/build/make_domain_coordinator.pl   
> indicates that there should be a manual procedure for adding a   
> domain coordinator. When I traced through that manual procedure, I   
> got through the first 8 steps (finding that nothing needed to be   
> done for them) and then tried in vain to find a file called   
> rolesmanip.ip. Not only is it not anywhere under   
> /root/loncapa-2.7.1, but I still have tarballs going all the way   
> back to loncapa-1.3.2.tar.gz and none of them contain a file called   
> rolesmanip.pl. So the question is whether the filename inside   
> make_domain_coordinator.pl is incorrect and I should have been   
> looking for a different filename or whether there is really no   
> manual procedure at all.
> Anyway, I've been trying to write up a report on the procedure I   
> used to do the upgrade, including the pitfalls I have encountered.   
> I'd like to include something about this part too. Once I decide   
> that I know as much as I am going to know, I'll submit it to this   
> list.
> Best Regards to all,
> Paul
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin

More information about the LON-CAPA-admin mailing list