possibly weird config requests...
This may be a list of weird requests but our Galaxy server runs internally and is only accessible to our users so I'd like to make it a bit easier to manage. I could customize a copy but hopefully some of the "features" I'm after are already available. If not, I'm happy to work on them and integrate if others think they'll be useful. * Rather than email address as usernames, we'd rather just use our corporate logins (lastname, first initial, eg.mine is smithiesr) Or can I have an alias list (like samba)? * Is there a bulk user creation script? Rather than have everyone create their own account, I'd rather do them all at once. It's not that I don't trust users but... * Can I have every user's home dir automagiclly added as a data dir? eg. I'd like to have /home/smithiesr available. Would be nice if this was part of a bulk useradd script * Any chance of AD integration? I have no idea if Python plays well with Active Directory and/or LDAP. * Is it possible to add new tools without restarting Galaxy? I know tool configs can be reloaded from the admin console but I'd like our users to be able to incorporate their existing scripts as tools. Would a local tool-shed make this easier? * We use NTLM for authentication on most of our internal sites - am I going to have problems getting Galaxy/Python to authenticate? A few years ago we ran into the same requirement with a Java app so ended up hacking together a script that passed SSO creds to Internet Exploiter for authentication. Sorry if some of these sound dumb or are already implemented, I'm still reading thru the docs. Thanx, Russell Smithies Infrastructure Team T 03 489 9085 M 0274 734 600 E russell.smithies@agresearch.co.nz Invermay Agricultural Centre Puddle Alley, Private Bag 50034, Mosgiel 9053, New Zealand T +64 3 489 3809 F +64 3 489 3739 www.agresearch.co.nz ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
Hi Russell, Just addressing AD/LDAP authentication - authentication is trivially and best (IMHO) left to an external (eg apache) proxy - save yourself a lot of effort - it's known to work well. Lock down the paste process so it only talks to your apache and provide pass through authentication. Doing that deals with your first and second questions since galaxy will create new users as they appear if appropriately configured - although you are stuck with user@yourconfigured.domain as the user ids inside Galaxy even though the user authenticates with the sAMAccountName in the example below so it's the same login for all our AD logins. The recipe has been posted a few times and should be easy to find using a search. Something like: <Location /galaxy> Options FollowSymLinks AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative Off AuthName "BHRI LDAP" Order Allow,Deny Allow From All Require valid-user AuthLDAPBindDN "user@domain" AuthLDAPBindPassword "passwordforuser@domain" AuthLDAPURL "ldap:// 172.16.1.245:389/OU=Baker,DC=bhri,DC=internal?sAMAccountName?sub?(objectClass=*) " RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e </Location> works for us on a local AD server On Mon, Dec 5, 2011 at 9:21 AM, Smithies, Russell < Russell.Smithies@agresearch.co.nz> wrote:
This may be a list of weird requests but our Galaxy server runs internally and is only accessible to our users so I’d like to make it a bit easier to manage.****
I could customize a copy but hopefully some of the “features” I’m after are already available. If not, I’m happy to work on them and integrate if others think they’ll be useful.****
** **
**· **Rather than email address as usernames, we’d rather just use our corporate logins (lastname, first initial, eg.mine is smithiesr) Or can I have an alias list (like samba)?****
**· **Is there a bulk user creation script? Rather than have everyone create their own account, I’d rather do them all at once. It’s not that I don’t trust users but…****
**· **Can I have every user’s home dir automagiclly added as a data dir? eg. I’d like to have /home/smithiesr available. Would be nice if this was part of a bulk useradd script ****
**· **Any chance of AD integration? I have no idea if Python plays well with Active Directory and/or LDAP.****
**· **Is it possible to add new tools without restarting Galaxy? I know tool configs can be reloaded from the admin console but I’d like our users to be able to incorporate their existing scripts as tools. Would a local tool-shed make this easier? ****
**· **We use NTLM for authentication on most of our internal sites – am I going to have problems getting Galaxy/Python to authenticate? A few years ago we ran into the same requirement with a Java app so ended up hacking together a script that passed SSO creds to Internet Exploiter for authentication. ****
** **
Sorry if some of these sound dumb or are already implemented, I’m still reading thru the docs.****
** **
Thanx,****
*Russell Smithies* Infrastructure Team****
*T* 03 489 9085 *M* 0274 734 600 *E* russell.smithies@agresearch.co.nz****
Invermay Agricultural Centre Puddle Alley, Private Bag 50034, Mosgiel 9053, New Zealand****
*T * +64 3 489 3809 *F* +64 3 489 3739 *www.agresearch.co.nz*****
** **
------------------------------
*Attention: *The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately.
------------------------------
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
-- Ross Lazarus MBBS MPH; Associate Professor, Harvard Medical School; Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444;
On Dec 4, 2011, at 5:39 PM, Ross wrote:
Hi Russell,
Just addressing AD/LDAP authentication - authentication is trivially and best (IMHO) left to an external (eg apache) proxy - save yourself a lot of effort - it's known to work well. Lock down the paste process so it only talks to your apache and provide pass through authentication. Doing that deals with your first and second questions since galaxy will create new users as they appear if appropriately configured - although you are stuck with user@yourconfigured.domain as the user ids inside Galaxy even though the user authenticates with the sAMAccountName in the example below so it's the same login for all our AD logins.
The recipe has been posted a few times and should be easy to find using a search.
Something like:
<Location /galaxy> Options FollowSymLinks AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative Off AuthName "BHRI LDAP" Order Allow,Deny Allow From All Require valid-user AuthLDAPBindDN "user@domain" AuthLDAPBindPassword "passwordforuser@domain" AuthLDAPURL "ldap://172.16.1.245:389/OU=Baker,DC=bhri,DC=internal?sAMAccountName?sub?(objectClass=*)" RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e </Location>
works for us on a local AD server
The documentation for the feature explained by Ross is here: http://usegalaxy.org/production Responses to other questions follow:
On Mon, Dec 5, 2011 at 9:21 AM, Smithies, Russell <Russell.Smithies@agresearch.co.nz> wrote: This may be a list of weird requests but our Galaxy server runs internally and is only accessible to our users so I’d like to make it a bit easier to manage.
I could customize a copy but hopefully some of the “features” I’m after are already available. If not, I’m happy to work on them and integrate if others think they’ll be useful.
· Rather than email address as usernames, we’d rather just use our corporate logins (lastname, first initial, eg.mine is smithiesr) Or can I have an alias list (like samba)?
I know this has been hacked in by another person in their instance, but you should also not really need to do this if you use the authentication via proxy as explained above.
· Is there a bulk user creation script? Rather than have everyone create their own account, I’d rather do them all at once. It’s not that I don’t trust users but…
Accounts are automatically created when authentication is delegated to the upstream proxy server.
· Can I have every user’s home dir automagiclly added as a data dir? eg. I’d like to have /home/smithiesr available. Would be nice if this was part of a bulk useradd script
Sort of. You could create a directory of symlinks named as the user's Galaxy email address that link to their home directories and then set this directory as the value of ftp_upload_dir. The user would then see the contents of his or her home directory on the upload form (but I imagine this would be quite slow for large directories). Instead of their entire directory, I'd suggest using a subdirectory or another designated space on the filesystem. Importing to a history via the Upload tool may fail if the Galaxy user is unable to write to the file and/or directory since this is not what the FTP upload functionality was originally designed for. Documentation is here (not all of it is relevant to this non-FTP usage): http://wiki.g2.bx.psu.edu/Admin/Config/Upload%20via%20FTP
· Any chance of AD integration? I have no idea if Python plays well with Active Directory and/or LDAP.
· Is it possible to add new tools without restarting Galaxy? I know tool configs can be reloaded from the admin console but I’d like our users to be able to incorporate their existing scripts as tools. Would a local tool-shed make this easier?
The public tool shed or a local tool shed would allow for this. Note that users still need administrative privileges to install tools from a tool shed. --nate
· We use NTLM for authentication on most of our internal sites – am I going to have problems getting Galaxy/Python to authenticate? A few years ago we ran into the same requirement with a Java app so ended up hacking together a script that passed SSO creds to Internet Exploiter for authentication.
Sorry if some of these sound dumb or are already implemented, I’m still reading thru the docs.
Thanx,
Russell Smithies Infrastructure Team
T 03 489 9085 M 0274 734 600 E russell.smithies@agresearch.co.nz
Invermay Agricultural Centre Puddle Alley, Private Bag 50034, Mosgiel 9053, New Zealand
T +64 3 489 3809 F +64 3 489 3739 www.agresearch.co.nz
Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately.
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
-- Ross Lazarus MBBS MPH; Associate Professor, Harvard Medical School; Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444; ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
Thanx guys, that should give me heaps to go on with :-) --Russell
-----Original Message----- From: Nate Coraor [mailto:nate@bx.psu.edu] Sent: Tuesday, 6 December 2011 8:21 a.m. To: Ross Cc: Smithies, Russell; galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] possibly weird config requests...
On Dec 4, 2011, at 5:39 PM, Ross wrote:
Hi Russell,
Just addressing AD/LDAP authentication - authentication is trivially and best (IMHO) left to an external (eg apache) proxy - save yourself a lot of effort - it's known to work well. Lock down the paste process so it only talks to your apache and provide pass through authentication. Doing that deals with your first and second questions since galaxy will create new users as they appear if appropriately configured - although you are stuck with user@yourconfigured.domain as the user ids inside Galaxy even though the user authenticates with the sAMAccountName in the example below so it's the same login for all our AD logins.
The recipe has been posted a few times and should be easy to find using a search.
Something like:
<Location /galaxy> Options FollowSymLinks AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative Off AuthName "BHRI LDAP" Order Allow,Deny Allow From All Require valid-user AuthLDAPBindDN "user@domain" AuthLDAPBindPassword "passwordforuser@domain" AuthLDAPURL "ldap://172.16.1.245:389/OU=Baker,DC=bhri,DC=internal?sAMAccountName ?sub?(objectClass=*)" RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e </Location>
works for us on a local AD server
The documentation for the feature explained by Ross is here:
http://usegalaxy.org/production
Responses to other questions follow:
On Mon, Dec 5, 2011 at 9:21 AM, Smithies, Russell
This may be a list of weird requests but our Galaxy server runs internally and is only accessible to our users so I'd like to make it a bit easier to manage.
I could customize a copy but hopefully some of the "features" I'm after are already available. If not, I'm happy to work on them and integrate if others
<Russell.Smithies@agresearch.co.nz> wrote: think they'll be useful.
* Rather than email address as usernames, we'd rather just use our
corporate logins (lastname, first initial, eg.mine is smithiesr) Or can I have an alias list (like samba)?
I know this has been hacked in by another person in their instance, but you should also not really need to do this if you use the authentication via proxy as explained above.
* Is there a bulk user creation script? Rather than have everyone create their own account, I'd rather do them all at once. It's not that I don't trust users but...
Accounts are automatically created when authentication is delegated to the upstream proxy server.
* Can I have every user's home dir automagiclly added as a data dir? eg. I'd like to have /home/smithiesr available. Would be nice if this was part of a bulk useradd script
Sort of. You could create a directory of symlinks named as the user's Galaxy email address that link to their home directories and then set this directory as the value of ftp_upload_dir. The user would then see the contents of his or her home directory on the upload form (but I imagine this would be quite slow for large directories). Instead of their entire directory, I'd suggest using a subdirectory or another designated space on the filesystem.
Importing to a history via the Upload tool may fail if the Galaxy user is unable to write to the file and/or directory since this is not what the FTP upload functionality was originally designed for. Documentation is here (not all of it is relevant to this non-FTP usage):
http://wiki.g2.bx.psu.edu/Admin/Config/Upload%20via%20FTP
* Any chance of AD integration? I have no idea if Python plays well with Active Directory and/or LDAP.
* Is it possible to add new tools without restarting Galaxy? I know tool configs can be reloaded from the admin console but I'd like our users to be able to incorporate their existing scripts as tools. Would a local tool-shed make this easier?
The public tool shed or a local tool shed would allow for this. Note that users still need administrative privileges to install tools from a tool shed.
--nate
* We use NTLM for authentication on most of our internal sites - am I going to have problems getting Galaxy/Python to authenticate? A few years ago we ran into the same requirement with a Java app so ended up hacking together a script that passed SSO creds to Internet Exploiter for authentication.
Sorry if some of these sound dumb or are already implemented, I'm still reading thru the docs.
Thanx,
Russell Smithies Infrastructure Team
T 03 489 9085 M 0274 734 600 E russell.smithies@agresearch.co.nz
Invermay Agricultural Centre Puddle Alley, Private Bag 50034, Mosgiel 9053, New Zealand
T +64 3 489 3809 F +64 3 489 3739 www.agresearch.co.nz
Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately.
__________________________________________________________ _
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
-- Ross Lazarus MBBS MPH; Associate Professor, Harvard Medical School; Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444;
__________________________________________________________ _
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
participants (3)
-
Nate Coraor -
Ross -
Smithies, Russell