Wow that was a long title, but just what I have been dealing with recently. The first
solution which, is easy, is to use Kerberos, this works great unless you also want
to fall back to a standard.htpasswd` file. In that case you need
to use LDAP. Why? because LDAP and File use the same AuthType of Basic where as
Kerberos uses an AuthType of Kerberos. Using LDAP and File authentication you can
use a config like this
AuthBasicProvider ldap file
# File Auth
This works unless you have your users split over a number of OUs in the Active
Directory. If that is the case here is the way I got around it.
<AuthnProviderAlias ldap ldap-group1>
<AuthnProviderAlias ldap ldap-group2>
AuthBasicProvider ldap-group1 ldap-group2 file
# File Auth
When using a series of commands tied together with pipes I usually start with the cat
command. A lot of times when I post a one liner solution on a forum someone will reply
that there was no point in starting with cat as it is inefficient. So I decided to put
a quick post about why I use cat rather than one of the other methods.
The main reason that I use cat at the start of most strings of pipes is that it is
easier to maintain. The logical flow of the data is going from left to right and the
files that go into the pipe is easy to spot e.g.
cat /etc/passwd | grep bash | grep -v :x:
We can see here that
/etc/passwd gets pushed through grep first to find those lines
containing bash. Then those lines are pushed through grep again looking for lines that
:x: (i.e. non shadowed passwords). This could have been written in a
number of different ways.
grep bash /etc/passwd | grep -v :x:
</etc/passwd | grep bash | grep -v :x:
In these examples the first way would be reasonable, but the original file at the start
of the pipe is a little hidden tucked away in the first grep command. The second way
puts the original file at the start and is very clear, but a typo of
> instead of
will destroy the file I am really wanting to read from.
So yes there are more efficient ways to start off a string of pipes, but I like to to
use cat as it makes things a bit more obvious than some and less prone to destroying
data with a simple typo than others.
Well I have just figured out why some of the machines that I use had stopped picking up updates. When
I look at the list of systems on the RedHat Network they had a list of updates that they hadn’t picked
up but when I logged into the machines and ran
it said there were no updates. After trying a lot of things on one of the systems that I was free to
test with I still couldn’t find out what was going on. Eventually I discovered that yum had corrupted
it’s cache and so it thought that its list of packages was up to date when it wasn’t. The solution
was quite easy after that
yum clean all
I know, I should have tried that at the start.