[LON-CAPA-admin] Cloning production server for testing purposes

[Stefan Bisitz]

Argh, sorry, I meant localauth.pm, not localenroll.pm.

As the name already suggests, localenroll.pm is for enrollment (as you 
said) and localauth.pm for authentication.

After 5.5 years of LON-CAPA usage including our customized student's 
enrollment before self-enrollment was available, I should know the 
difference... ;-)

Stefan

On 06.07.2011 17:40 CEST, Stefan Bisitz wrote:
> On 06.07.2011 17:32 CEST, Lucas, Mark wrote:
>> Stefan,
>>
>> I'm not sure localenroll.pm will do what you think. It's for the auto
>> enrollment process, isn't
>> it? Or is there a routine in there that filters logins?
>
> It's used for configuring local authentication, e.g. LDAP what we use
> here. A customized subroutine retrieves user name and password of the
> one you tries to login and then connects to the local authentication
> system to check if this data is valid. It returns success/no success
> depending on the result.
>
> This could be changed to
> if ($username ne "bisitzspecialsuperuser") {
> return ...
> }
>
>
>> Under system configuration you can redirect logins to a different
>> machine except for from certain IP addresses.
>  > The only hitch I realized is that as far as I can tell, it
>> has to be another machine in
>> the cluster, which is hard to do when it's out of the cluster.
>
> I will check this.
>
>> The nice thing is that the emails are showing up within a few minutes of
>> going out. Thank you,
>> Stuart, for updating mailman!
>
> I guess our local greylist sometimes forgets about known senders and
> delays it or something like that.
>
> Stefan
>
>>
>> Mark
>>
>>
>> On Jul 6, 2011, at 11:19 AM, Stefan Bisitz wrote:
>>
>>> Thanks, Mark. This is helpful.
>>>
>>> To assure that no others than the tester personnel can login, I think I
>>> will adjust localenroll.pm.
>>>
>>> By the way: Funny to find your answer in my inbox before the actual
>>> question... :-)
>>>
>>> Stefan
>>>
>>>
>>> On 06.07.2011 16:28 CEST, Lucas, Mark wrote:
>>>> We have a development server that has the hostname oucapa2 and domain
>>>> ohiou,
>>>> the same as our main library server.
>>>>
>>>> Since it is in the development cluster, none of the machines in the
>>>> production cluster
>>>> know of it's existence. It does not interfere or confuse the production
>>>> cluster.
>>>>
>>>> It has a different IP address than the regular library server and
>>>> different hosts.tab and domain.tab.
>>>>
>>>> The only real risk is that a student somehow gets logged into the wrong
>>>> machine by
>>>> somehow getting the IP address of the development server (not a high
>>>> risk in my mind).
>>>>
>>>> At the last meeting we were actually talking about setting up a small
>>>> cluster in between
>>>> development and production, which cloned the full library servers at
>>>> several of the institutions.
>>>> This would provide a close-to-production environment for LC 3.0
>>>> testing.
>>>>
>>>> Hope this helps!
>>>>
>>>> Mark
>>>>
>>>> On Jul 6, 2011, at 10:02 AM, Stefan Bisitz wrote:
>>>>
>>>>> [06.07.2011 16:02 CEST]
>>>>>
>>>>> Hi,
>>>>>
>>>>> To avoid chaos, I want to make sure that my idea works.
>>>>>
>>>>> I'd like to clone one of our production servers for testing
>>>>> purposes. I
>>>>> do not need connection to the LON-CAPA cluster but I want to have all
>>>>> local users, problems and courses as well as the related data.
>>>>>
>>>>> Is it really okay to "copy" the whole server, configure it as
>>>>> "standalone" and connect it to the internet? Copy means to process
>>>>> most
>>>>> of the steps as described on http://loncapa.org/hardwareupgrade.html
>>>>> which is basically copying the home folder.
>>>>>
>>>>> Even not connecting it to the internet could mean to have two very
>>>>> similar servers in the same local network, e.g. domain and host id
>>>>> would
>>>>> be the same.
>>>>>
>>>>> Thanks in advance for sharing any doubts,
>>>>> Stefan Bisitz