Paul,
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
domain.
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:
unix:
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
MSU LON-CAPA group
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
>