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
russell.smith...@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.smith...@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
Re: [galaxy-dev] possibly weird config requests...
Thanx guys, that should give me heaps to go on with :-)
--Russell
-Original Message-
From: Nate Coraor [mailto:n...@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
russell.smith...@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.smith...@agresearch.co.nz
Invermay
Re: [galaxy-dev] possibly weird config requests...
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.smith...@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.smith...@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:
http://lists.bx.psu.edu/
--
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:
http://lists.bx.psu.edu/
