<LocationMatch “/NoAuth”>
Satisfy Any
Allow from all
Users from NIS are logged into RT. But if there is no such user, it
doesn’t fall back to RT login page. And after log in this user cannot
even change preferences. It says permission denied. I assume that users
are created without any privileges. How can I fix this? And how does an
admin log on to manage RT as $WebFallbackToInternalAuth is failing? I’m
using RT ver 2.1.88.
Thanks in advance.
Users from NIS are logged into RT. But if there is no such user, it
doesn’t fall back to RT login page. And after log in this user cannot
even change preferences. It says permission denied. I assume that users
are created without any privileges. How can I fix this? And how does an
admin log on to manage RT as $WebFallbackToInternalAuth is failing? I’m
using RT ver 2.1.88.
This is what I did for RT 3.0.8, you might be able to reuse that, I
guess the code hasn’t changed that much over 2.1. It requires the
attached patch to html/autohandler. It doesn’t use external
authentication, instead the autohandler itself tries NIS authentication
first and if that fails, it falls back to the database.
Users from NIS are logged into RT. But if there is no such user, it
doesn’t fall back to RT login page. And after log in this user cannot
even change preferences. It says permission denied. I assume that users
are created without any privileges. How can I fix this?
The user attributes used with $WebExternalAuto are set in
Interfaces::Web::WebExternalAutoInfo. It’s straightforward to overlay
that function. However, it does default to creating Privledged users,
so I’m not sure what you’re seeing. Are the users actually created? Do
you have a strange ACL setup?
And how does an admin log on to manage RT as
$WebFallbackToInternalAuth is failing? I’m using RT ver 2.1.88.
What do you mean failing? Looking at your httpd,conf snippet, I don’t
see how apache would ever let you hit RT without a valid REMOTE_USER,
so WebFallbackToInternalAuth is never invoked, only WebExternalAuto.
Users from NIS are logged into RT. But if there is no such user, it
doesn’t fall back to RT login page. And after log in this user cannot
even change preferences. It says permission denied. I assume that
users
are created without any privileges. How can I fix this?
The user attributes used with $WebExternalAuto are set in
Interfaces::Web::WebExternalAutoInfo. It’s straightforward to overlay
that function. However, it does default to creating Privledged users,
so I’m not sure what you’re seeing. Are the users actually created? Do
you have a strange ACL setup?
Well users are created and this user can create a ticket but not change
their own preferences like nickname. Getting an error message Permission
denied. I was wrong about privileges as autohandler has SetPrivileged(1)
for users. But why can’t I change my own info when logged in?
And how does an admin log on to manage RT as
$WebFallbackToInternalAuth is failing? I’m using RT ver 2.1.88.
What do you mean failing? Looking at your httpd,conf snippet, I don’t
see how apache would ever let you hit RT without a valid REMOTE_USER,
so WebFallbackToInternalAuth is never invoked, only WebExternalAuto.
Oh ok. So as admin is set as REMOTE_USER it doesn’t fallback. Is there
any way I can tell apache not to authenticate for ‘admin’ against NIS
but against RT database?
Well users are created and this user can create a ticket but not change
their own preferences like nickname. Getting an error message Permission
denied. I was wrong about privileges as autohandler has SetPrivileged(1)
for users. But why can’t I change my own info when logged in?
What is your ACL setup? maybe you don’t like Everyone ModifySelf?
What do you mean failing? Looking at your httpd,conf snippet, I don’t
see how apache would ever let you hit RT without a valid REMOTE_USER,
so WebFallbackToInternalAuth is never invoked, only WebExternalAuto.
Oh ok. So as admin is set as REMOTE_USER it doesn’t fallback. Is there
any way I can tell apache not to authenticate for ‘admin’ against NIS
but against RT database?
I’m not sure how’d you’d tell apache to never authenticate certain
usernames. For myself, I’d create a “seph/admin” user, and have RT
canonicalize all the /admin users to root.
What is your ACL setup? maybe you don’t like Everyone ModifySelf?
Thanks seph! That was what was missing.
I’m not sure how’d you’d tell apache to never authenticate certain
usernames. For myself, I’d create a “seph/admin” user, and have RT
canonicalize all the /admin users to root.
Hmm… the main reason for a super-user is to grant/revoke rights. Do all
privileged users have this right by default? There should be some way of
saying that 1 user is a super-user. Is there anything akin to
SetPrivileged(1) that I can specify by way of code?
Hmm… the main reason for a super-user is to grant/revoke rights. Do all
privileged users have this right by default? There should be some way of
saying that 1 user is a super-user. Is there anything akin to
SetPrivileged(1) that I can specify by way of code?
Users from NIS are logged into RT. But if there is no such user, it
doesn’t fall back to RT login page. And after log in this user cannot
even change preferences. It says permission denied. I assume that
users
are created without any privileges. How can I fix this? And how does
an
admin log on to manage RT as $WebFallbackToInternalAuth is failing?
I’m
using RT ver 2.1.88.
This is what I did for RT 3.0.8, you might be able to reuse that, I
guess the code hasn’t changed that much over 2.1. It requires the
attached patch to html/autohandler. It doesn’t use external
authentication, instead the autohandler itself tries NIS
authentication
first and if that fails, it falls back to the database.
Thanks Fabian! Currently I’m trying to make the Apache-NIS work. If it
doesn’t work out the way I want it to, I’ll try the autohandler patch
(looks great!).
I hate jumping into the midst of a problem, especially when I don’t
understand the full scope of the issue, however, I do remember in Sun
Sys Admin I & II classes that our instructor warned us to stay away from
ACL’s if possible. I thought I odd that Sun would warn against it’s own
feature (although they did the same with NIS), but they did.
If you’re looking to allow certain users rights to certain
files/directories/etc, I would suggest SUDO. There are security risks
doing this (for example, if you give sudo vi you can shell out as root),
but it might be better than ACLs.
Hmm… the main reason for a super-user is to grant/revoke rights. Do
all
privileged users have this right by default? There should be some way
of
saying that 1 user is a super-user. Is there anything akin to
SetPrivileged(1) that I can specify by way of code?
I hate jumping into the midst of a problem, especially when I don’t
understand the full scope of the issue, however, I do remember in Sun
Sys Admin I & II classes that our instructor warned us to stay away from
ACL’s if possible. I thought I odd that Sun would warn against it’s own
feature (although they did the same with NIS), but they did.
next time, don’t jump so quickly. we’re talking about RT’s ACL
system. Not sun’s filesytem acls.
Hmm… the main reason for a super-user is to grant/revoke rights. Do
all
privileged users have this right by default? There should be some way
of
saying that 1 user is a super-user. Is there anything akin to
SetPrivileged(1) that I can specify by way of code?
yes. read the acl lists, or acl docs.
Acl docs … I found rt3 doc at bestpractical. A search for ACL in the
rt-users list turned up around 1018 hits. Could you point me to the docs
if you know where they are.
Thanks!
parimala
I hate jumping into the midst of a problem, especially when I don’t
understand the full scope of the issue, however, I do remember in Sun
Sys Admin I & II classes that our instructor warned us to stay away
from
ACL’s if possible. I thought I odd that Sun would warn against it’s
own
feature (although they did the same with NIS), but they did.
next time, don’t jump so quickly. we’re talking about RT’s ACL
system. Not sun’s filesytem acls.