@robb@syntaxerrormmm I would know if this setting is a mandatory, because it end by an error when I try to log with a Linux client and it fails back by the normal login. Therefore it is not nice to see it.
can we find a name convention here, ‘staff’ is enough good for me, but we could have another way.
In fact I’m really close to find how to authenticate directly in moodle, my concern is that during the web installation moodle is waiting a blank database, so all mysql Injection could be done only after the end of this process. I think that we could launch manually a script for inserting mysql data
I do not think Kerberos is mandatory. I would just like that (maybe optionally), you may use the users you created within LDAP as users also of the Moodle platform. Are you using the SAMBA DC container, right?[quote=“stephdl, post:18, topic:5029”]
can we find a name convention here, ‘staff’ is enough good for me, but we could have another way.
[/quote]
Yeah, I do not like it so much, but we may settle for it if we cannot find any valid alternatives. I would suggest Course Creators.[quote=“stephdl, post:18, topic:5029”]
so all mysql Injection could be done only after the end of this process. I think that we could launch manually a script for inserting mysql data
[/quote]
In my mind, all the setup should be silent and with little choice for the user. Basically, the scripts that are configuring the LDAP modules has to be injected right after the database has been created in the provided way by the RPM specfile, then we should leave a choice to the user (better if with a web module) to use internal users or LDAP/AD ones (a flag or a combo-box would be perfect). Only when the option to take users from LDAP/AD has been taken, we should run (internally inside an event) the last piece of SQL injection that will enable LDAP authentication with the chosen methods (and provide a way to fall back if the user changes his/her mind, also).
Well, at least this is what I will try to get to. A lot of work, I know, but this will make the module perfect for production.
Fine, completely understoodable [quote=“stephdl, post:20, topic:5029”]
I prefer on one word, not sure about side effects
[/quote]
Well, it should be a LDAP Common Name anyways, so spaces should be allowed. But I understand. How about replacing the space with an underscore, then?
Completely agree on the roadmap. Also injecting or not the configurations based on SSSD status would be a big plus, but it should be reversable anyways (maybe I don’t want to use LDAP users in a site in which I enabled LDAP).
How about creating a random one as it is done with LDAP or MySQL?
yes, doable but we need to let something to do at the enduser, it is also a matter to let a lot of contacts of the admin (name, email, phone etc)
Then the admin can disable the plugin manually in the configuration file, I don’t want to play too much on a database after the creation/installation.
In another hand it makes me think that the user can install moodle and see he miss about ldap or AD, so I might find a way to do an injection manually if needed.
Mmh, this makes me think on the approach we are taking.
Do we prefer a complete administration of LDAP/AD integration from NS WebGUI (I second this one, really) or we want to leave the user in charge of everything on the inside of Moodle?
I would not do half of the first approach and half of the second if I can, because it is confusing to the final user. Maybe I would also devise something to deny the user to tamper with the settings done via injection, if we decide to take the first route.
So, if the nethserver-moodle package has to setup authentication based on SSSD, I would expect to disable it from the NS WebGUI and not mess with the options inside Moodle anymore.
For optional strings within Moodle (like the Names of the admin user), I don’t see a problem here: if a system administrator wants to customize it, fine for me. Please take into account that LDAP backend doesn’t have all the fields required to compile the information, although AD does.
That’s the main point. I would take one of this two options:
Devise an event nethserver-moodle-update to check and change SQL accordingly to user inputs (enable/disable integration in the WebGUI or following the status of the system when installing), thus satisfying the needs for manageability from the NS WebGUI;
Leave completely the integration of AD/LDAP to the sysadmin.
I do think also the first one is feasible, but I don’t want to leave all the fun to you
Unfortunately I have a queue of stuff to do (for BgLUG, for TDF, for some schools, for this community) that I really don’t know when I’m able to check for it. Do you happen to know someone that sells some ubiquity, an additional pair of hands or additional 24 hours a day?
The Server Manager Users&Groups page sets only a minimal set of attributes. Additional attributes could be managed by other clients, like “phpLDAPadmin”, “AD RSAT tools”, or - why not - moodle itself.
I was talking about Moodle with @robb and others recently so I just installed Moodle 3.4 which needs PHP 7 which I took from nethserver-php-scl by @stephdl :
tried postgres 9.6 from SCL without success, now mariadb with mariadb connector is used
PHP 7.1
custom template /etc/e-smith/templates-custom/etc/opt/remi/php71/php.ini/90moodle for PHP7.1 settings
/etc/my.cnf.d/moodle.cnf for mysql config
This is just for the installation of the new version, for extra settings like AD check the first post of @robb and following…just copy/paste the following to a terminal:
Thanks a lot @mrmarkuz!
I also tried to install Moodle3.4, but did another approach: instead of installing in /var/www/html, I created a vhost and installed in /var/lib/nethserver/vhost/
Pro for this approach is tou can choose php7.x from netgui. I ran into problems that look liked a CSS problem. Con was that even though I changed permissions of the vhost to apache, the configuration script of Moodle during web install part went sour…
If php-scl can be used when installing in /var/www/html by using a custom template (wish I could create them… would love to get some insight info on that) It will be a lot easier to install.
In the previous version of Moodle (3.1, created by @areguera) there is a nice way of creating a custom url. Can this code be re-used for Moodle 3.4?
I noticed that Moodle writes a wwwroot property to its config file. When you connect via http at install it writes http to config and if you connect via https afterwards you have the CSS problem.
Here is the creation of the custom template for PHP7.1. I copied the content from the Moodle homepage.
It’s described here.
I am not a dbadmin and didn’t know that before I read the article but the GRANT command invokes a FLUSH. I know it’s used in plenty of tutorials but it seems to be obsolete.
Please check if the directory /var/www/html/moodle exists.
You simply could run the whole procedure again, existing db is kept.