Russ:
On Mon, 11 Jun 2007, Russ Allbery wrote:
Note that, if possible, the group is also created even if the keyring is
used.
Yes; this is true for now, but it's not something that should be relied
upon since the group is not always guaranteed to be there (e.g, when
calling getgroups()),
There is no good, portable way to do this. The traditional way that
OpenAFS kept track of PAGs was to assign a 24-bit identifier; this is then
extended to a 32-bit integer by setting the first 8 bits to the ASCII
value 'A' (for "AFS"), and letting the last 24 bits be the PAG ID.
This number i
Ken:
On Fri, 23 Mar 2007, Kenneth Baker wrote:
I am hoping to run a mixed environment with an amd64 kernel and a 32bit
user space (along with a few statically compiled 64 bit apps). Before I
try this I would like to know if the openafs user space tools running in
the 32bit user space will co
I just put together a PAM module which could be used for this purpose,
based on the Red Hat pam_krb5.so pam module. (my module decides whether
or not to do run an external 'aklog'-ish program depending upon policy)
If you just want krb5 authentication + AFS tokens, I would suggest looking
at
(I just entered a bug report with this same text as bug #31975)
When I try to click on the "Help" button in the OpenAFS GUI tools (either
the AFS Shell Extension, or the afscreds.exe program), the following error
message is displayed:
Cannot find the C:\Program Files\OpenAFS\Client\Progr
the excellent report.
Jeffrey Altman wrote:
We do not have a fully implementation of the Remote Administration
Protocol. This issue is listed in the "issues" list distributed
with the release.
Jeffrey Altman
Christopher Allen Wing wrote:
(I just entered a bug report with this sa
Thanks. It wasn't clear to me whether this was a known problem or if
something was broken in my system's configuration.
I was looking at documentation such as your status report from December:
https://www.secure-endpoints.com/talks/OpenAFS-Windows-Dec-2005-Status-Report.pdf
which see
(I just entered a bug report with this same text as bug #31903)
I am testing the OpenAFS Windows client on a XP SP2 machine which should be
reasonably up to date with patches. I cannot reliably browse the '\\afs' root
in Windows Explorer. Sometimes this works, but other times I get the error:
On Wed, 12 Apr 2006, O Plameras wrote:
Do you have any actual users in your AFS cell yet? Or did you just set it
up with kaserver for testing purposes?
I have only half-dozen users. Yes, I created new principals in the k5 DB and
reset afs key.
Ok. For such a small number of users, don'
The lack of prototypes in the AFS source code strikes again?
At one point last year I started trying to go through and add prototypes,
would there be an interest in patches that add prototypes and/or header
files where necessary?
-Chris
[EMAIL PROTECTED]
On Tue, 11 Apr 2006, Rainer Toebbic
Hello,
On Tue, 11 Apr 2006, O Plameras wrote:
I have running servers with OpenAFS-1.4.1 on FC5 using kaserver.
I have used clients running OpenAFS on FC4/Win2000 and
OpenAFS-1.4.1rc10 on FC5.
This setup is working without any problem so far.
Do you have any actual users in your AFS cell ye
On Thu, 6 Apr 2006, Derrick J Brashear wrote:
You might argue that these are really 3 different modes of operation and
they should belong in 3 different PAM modules. But on some Linux systems
at least this is all done by a single PAM module that figures out which of
those 3 things to do bas
Derrick:
On Thu, 6 Apr 2006, Derrick J Brashear wrote:
That doesn't sound quite right. Anyway, why would a pam module worth
anything honor the environment it was invoked with?
Mine certainly didn't.
Right, now I remember. It cleaned the environment and used the env extension
to export the
Rodney:
2. I'm curious as to why no one responded to the problem with xlock and
xscreensavers relating to PAM, K5 tickets, and tokens. Is this some kind
of state secret, or are we the only ones with the problem? To summarize
again...
On Linux the xscreensaver runs as the user but appea
Jeff:
On Wed, 25 Jan 2006, Jeffrey Hutzelman wrote:
/afs/cs.cmu.edu/misc/afstools
without any luck. This program does not seem to have any effect (both on
the file servers which are showing a problem, and on those which are
not). Is this program expected to work against 1.2.13 fileser
I should also add that I tried using the 'flushcps' program from:
/afs/cs.cmu.edu/misc/afstools
without any luck. This program does not seem to have any effect (both on
the file servers which are showing a problem, and on those which are not).
Is this program expected to work against 1
Hi. We are having a permissions problem with pts groups containing IP
addresses. It looks like this may be a bug in the 1.2.13 fileserver.
Our cell configuration is as follows:
- fileservers running openafs 1.2.13 on Solaris 9 (sparc)
We are running the binaries from openafs.o
Hi Kevin!!
Kevin Coffman wrote:
Yea. I just decided to ignore those. I suppose I could try to build and
install fakeka if people seem to want it.
fakeka comes with the MIT Kerberos code now and Heimdal already has afs
stuff, so I don't think there's a need.
fakeka isn't built by default
Derek:
Hmm. I ended up rebuilding all the RPMs from the openafs site in the past
year because there were no x86_64 packages.
That's because I have no x86_64 hardware, and vmware doesn't emulate x86_64.
We need to start a collection and get you some money and/or x86_64
hardware. Seriously, y
Derek:
I didn't realize you had put packages up already. (I didn't bother to go
looking, I only checked out what was linked from the website)
I see you are also supporting Linux 2.4. I didn't bother to put in the
work since I only cared about deploying RHEL 4.
Solaris I'll believe. I'm on
There are also a number of other patches to afs-krb5 I've accumulated in:
I've grabbed some that I consider relevant. I didn't grab all of them. I
tried
to ignore the UMich-specific stuff, and as I don't build/install afs2k5db I
just ignored that set completely.
Sure. Most are build fixes
Ah. Ummm that's probably there because we had a dependency on linking
all Kerberos programs with -lresolv because we used the DNS code before it
made it into the mainline MIT tree. But since various bits of the kit
are making it into other packages, I've stopped caring about making the
mi
Here, we just use a single rule to allow incoming traffic on UDP port 7001
for callbacks:
-A RH-Firewall-1-INPUT -p udp --dport 7001 -j ACCEPT
so that hosts can communicate with any AFS cell. (due to the callback
issue that Russ describes)
This is assuming a standard RHEL3/RHEL4/rec
Dirk:
Did you test 2.1.8-2 from=20
http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ ?
I took a look at the code and it looks like they fixed the bugs there.
Unfortunately the bugzilla entries for RHEL4 have languished and the RHEL4
pam_krb5 still hasn't been update
I updated the RHEL4 RPMs to the 1.4.0-rc1 release.
Changes between the previous (1.3.87) RPMs and these RPMs:
- I included Russ Allbery's patch from RT #18767 to fix the shared
library versioning on Linux (set the ELF SONAME properly). This
will fix the RPM dependency
I updated the RHEL4 RPMs to the 1.3.87 release.
I made no changes between the 1.3.86 RPMs and these, except for updating
the OpenAFS source.
You can download the 1.3.87 packages for i386 and x86_64 from:
http://www-personal.engin.umich.edu/~wingc/openafs/dist/1.3.87
Note that the p
John:
If you want to preserve a little bit more of the metadata in the kaserver
database when converting to Kerberos 5, take a look at:
http://www-personal.engin.umich.edu/~wingc/openafs/dist/1.3.86/SOURCES/afs-krb5-2.0-betterka2dump.patch
this is a patch against 'afs2k5db' which do
I updated the RHEL4 RPMs to the 1.3.86 release.
The only changes I made from the 1.3.85 RPMs, aside from updating to
1.3.86, are:
- dropped obsolete patches
- added minor aklog cleanup patch
You can download the 1.3.86 packages for i386 and x86_64 from:
http://www-per
nt and
openafs-kernel RPMs. I'm not sure.
-Chris
[EMAIL PROTECTED]
On Tue, 19 Jul 2005, Christopher Allen Wing wrote:
Ron:
The 1.2.13 RPMs from openafs.org will not build on x86_64. A few slight
changes are needed to get it to work.
Here is our version of the 1.2.13 RPMs; you can c
Ron:
The 1.2.13 RPMs from openafs.org will not build on x86_64. A few slight changes
are needed to get it to work.
Here is our version of the 1.2.13 RPMs; you can compare the spec file inside
with the original one from openafs.org to see what I changed.
http://www-personal.engin.um
On Mon, 18 Jul 2005, Russ Allbery wrote:
ChallengeResponseAuthentication no
in /etc/ssh/sshd_config and see if that fixes your problem?
This breaks password expiration, or any other PAM dialogs that require
anything more complex than a simple password prompt.
Yes, but I'm guessing
Ha. My theory about 'improper UID' was incorrect, but I did find the
underlying cause.
When 'keyboard-interactive' mode is in use, OpenSSH forks off a separate
process to do PAM authentication. This process then dies, and thus the
credentials cache (which is stored in memory) goes away.
Whe
Kurt:
Sorry, I was wrong about the PID being different pointing to a problem. I
had misread our log files here, thinking that on our systems, the pid
didn't change between auth and session phase.
Actually, it looks like the problem is 'keyboard-interactive'
authentication in sshd. This seem
See also:
http://bugzilla.mindrot.org/show_bug.cgi?id=688
This is apparently a known issue (ChallengeResponseAuthentication does not
work properly with PAM). It's in the FAQ:
http://www.openssh.com/faq.html#3.15
-Chris
___
OpenAF
On Fri, 15 Jul 2005, Kurt Seiffert wrote:
The only think I did for the sshd was to turn off PubKey authentication and
turn on PAM authentication.
PAM is enabled by default, and pubkey shouldn't make a difference.
Is this the standard sshd that comes with RHEL4, or your own?
The interaction
Ted,
On Fri, 15 Jul 2005, ted creedon wrote:
You should try building aklog in the
openafs source tree, not from the afs-krb5 source tree. Does that work?
No. In fact new make messages are being emitted stating that that build
step has been bybassed.
Did you enable krb5 when you ran ./
Ron:
The existing 1.2.13 OpenAFS RPM works fine for the client, with a few
changes. We are using it on RHEL3 for x86_64 without any problems.
Here is the build that we use (binary and source RPMs):
http://www-personal.engin.umich.edu/~wingc/openafs/dist/1.2.13/
Note that the pam_a
Ted,
On Thu, 14 Jul 2005, ted creedon wrote:
no - compiling all from scratch
All I did was take the existing 1.3.85 source and package it in a way that
is useful for RHEL4. If you are not running RHEL4 or if you don't want to
use RPMs, that I suggest you obtain the generic source code from
Ted:
RE:
http://www-personal.engin.umich.edu/~wingc/openafs/dist/1.3.85/SRPMS/openafs
-1.3.85-rhel4.0.src.rpm
1. afs-krb5 does not seem to be in this rpm
It's in there (afs-krb5-2.0.tar.gz)
2. the afs sources compile and run fine on SUSE 9.3 (2.6 kernel). Even
./configure works
Do you me
Ted:
aklog, asetkey, fakeka, ka-forwarder, afs2k5db, and keyfile_dump are all
included in these RPMs, in the 'openafs-krb5' and 'openafs-server-krb5'
packages. They should all work; I've tested aklog and asetkey.
I also made a few patches to afs2k5db to improve the database conversion
from k
Kurt:
The RHEL4 version of pam_krb5 is known to be broken in some AFS
environments (won't get tokens). It should get krb5 tickets, though, if
everything is configured properly.
Do you have a standard /etc/ssh/sshd_config file, or has this been
customized?
Are you using SELinux in the norm
I updated the RHEL4 RPMs to the 1.3.85 release.
I made the following changes:
- since it appears to be under active development now, I packaged
the aklog from the openafs source, instead of the one from the
afs-krb5 migration kit.
- tweak the module version ma
I updated the RHEL4 RPMs to the 1.3.84 release.
I made the following changes:
- added the latest RHEL4 kernel (2.6.9-11)
- removed old errata kernel (2.6.9-5.0.3)
- updated CellServDB to latest version from central.org
- The older init script tried to find the liba
Troy:
On Sat, 7 May 2005, Troy Benjegerdes wrote:
> This is not directly related to openafs, but does this module support
> allowing users to change expired kerberos passwords via ssh
> keyboard-interactive login?
I don't know; the module was written by Red Hat, not by me.
I think that it wil
Matthew:
See bugzilla #157107, #157109, #157111, #157113:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157107
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157109
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157111
https://bugzilla.redhat.com
Several people have been asking me as well as the OpenAFS list about
problems with the pam_krb5 PAM module included with Red Hat Enterprise
Linux 4. It has several bugs, including:
- doesn't work properly with dynroot enabled
- may not work when your 'root.cell' volume is replicate
I updated the RHEL4 RPMs to the 1.3.82 release.
I made the following changes:
- removed patches that are no longer necessary
- split off the documentation into separate packages; the HTML
files are now in a new 'openafs-docs' package, the PDF
documentation is i
I rebuilt the RHEL4 RPMs I created earlier this month against today's CVS,
using the openafs-stable-1_4_x branch.
I made the following changes:
- updated the spec file to allow building from CVS
- removed patches that are no longer necessary
- included the PAM modules agai
On Tue, 26 Apr 2005, Dj Merrill wrote:
> Hi Chris,
> Thanks for all the work in maintaining the
> pam_krb5 program
Thanks, but I haven't contributed anything to pam_krb5 myself. I just
noticed like you that it didn't work properly in RHEL4.
> If I leave things as they are (using th
> One interesting note is that "klist" under
> 3.4 gives an entry for "[EMAIL PROTECTED]"
> whereas for 4 it does not. However, it seems to work - I can
> access files in AFS, etc.
pam_krb5 in RHEL4 no longer uses the Kerberos ticket file directly to
obtain AFS tokens; this is why it does
> As per the K5 migration info, I have an afs principal:
> [EMAIL PROTECTED]
> however, I note that the pam_krb5afs tries several other
> combinations, but not this one exactly. For example, it tries
> [EMAIL PROTECTED], afs/[EMAIL PROTECTED], and
> afs/[EMAIL PROTECTED]
As Douglas suggests
> As per the K5 migration info, I have an afs principal:
> [EMAIL PROTECTED] however, I note that the pam_krb5afs tries several other
> combinations, but not this one exactly. For example, it tries
> [EMAIL PROTECTED], afs/[EMAIL PROTECTED], and
> afs/[EMAIL PROTECTED]
It looks like it tr
Frode:
The pam_krb5 module that comes with Red Hat should be able to obtain
tokens. Note that it may have some bugs:
- it may not work with dynroot enabled
- it may not work when you have more than 1 AFS database server
At some point I will try to get patches to Red Hat to fix t
I sent this to openafs-devel last Friday; I'm re-sending it to
openafs-info in case there are more people interested on this list.
I made some preliminary RPMs of the latest development release of OpenAFS
for Red Hat Enterprise Linux 4. I tried to stay as close as possible to
the existing RPMs cu
vsftpd in red hat 9 seems mostly sane with its PAM support, except that it
never calls PAM_DELETE_CRED so the tokens stay around forever.
The PAM support in older versions of wu-ftpd was quite broken.
Of course the best solution is to not run ftpd at all and just worry about
openssh working prop
Sure, that also works. I guess there are several pieces of advice:
1. Don't get AFS tokens as root if at all possible
2. If you need to get AFS tokens as root, make sure that you
obtain a new PAG first.
3. Make sure that the FTP server is behaving properly. Of
You can use the -dynroot afsd option; this will start up AFS and not
actually attempt to contact your cell's servers until a process actually
tries to use /afs.
The disadvantage is that /afs will be a fake directory created from the
contents of CellServDB, not the root.afs volume in your cell. (wh
57 matches
Mail list logo
