On Thu, 2010-05-27 at 09:09 -0400, Rob Crittenden wrote:
I assume the keytab is still valid since the mount succeeds and root
works. Kerberos otherwise works ok on this machine, you can kinit, etc?
Hm, the server didn't change, and on the client klist
-k /etc/krb5.keytab -e does not suggest
On Thu, 2010-05-27 at 12:27 -0400, Simo Sorce wrote:
Try adding allow_weak_crypto = true to your krb5.conf or alternatively
rekey your NFS credentials to add RC4/AES keys (rekeying works only if
both client and server kernels supporting anything but DES, I think
F13's kernels should have
On Thu, 2010-05-27 at 14:30 -0400, Simo Sorce wrote:
Oh right,
then I guess you need to look into syslog to see if you can find any
other hint.
does the gssd daemon log anything ?
It can be made to talk, like this:
rpc.gssd -f -vv -rr
Messages at startup:
Warning: rpcsec_gss
Since I upgraded about two days ago from a fully up-to-date and working
Fedora13 system to Fedora14, I am unable to mount the krb5p nfs4 shares
of the freeipa server (which is itself running a fully up-to-date
Fedora12).
rpc.gssd on the client reports the following:
beginning poll
Hi,
after upgrading a F12 freeipa server to F14, krb5 nfs no longer works.
1) ipa-getkeytab works only very unreliably. I get the following about 4
out of 5 times:
# ipa-getkeytab -s 192.168.1.2 -p nfs/client..xxx -k /etc/krb5.keytab
Operation failed! Unable to set key
ipa-delservice,
On Mon, 2010-12-06 at 10:55 -0500, Simo Sorce wrote:
Hi Simo,
thanks for your response!
We are seeing an issue with F14 DS where it has been built against
opneldap libraries while we still have plugins built against mozldap.
Where would that help?
just for the ipa-getkeytab reliability
On Mon, 2010-12-06 at 13:35 -0500, Simo Sorce wrote:
Keys are stored in ldap and asn.1 encoding is generated using ldap
libraries before storing it.
If that operation fails it may generate malformed entries that the KDC
later can't properly decode.
Which patch are you talking about? Is it
On Mon, 2010-12-06 at 13:53 -0500, Simo Sorce wrote:
Hi Simo,
I pushed the patch in git just today :)
Your patch indeed helps :)
I've adapted it to the fc14 srpm, compiled it, and at least the extop
plugin now uses the openldap libraries:
On Wed, 2010-12-08 at 11:00 -0500, Simo Sorce wrote:
On Tue, 07 Dec 2010 10:51:55 +0100
Thomas Sailer sai...@sailer.dynip.lugs.ch wrote:
On Mon, 2010-12-06 at 13:53 -0500, Simo Sorce wrote:
However krb5nfs still does not work, it hangs now (instead of giving
me an instantaneous error
Hi,
Installing a v2 freeipa server failed for me at the stage configuring
certificate server instance
The machine is an updated (and now fully up2date) fedora16 x64 machine.
Here's the command line output:
Configuring certificate server: Estimated time 3 minutes 30 seconds
[1/17]: creating
On 11/16/2011 03:14 PM, Alexander Bokovoy wrote:
maybe that's because server..com resolves to IPv6 address? We pass
FQDN of the server to pkisilent, and then it tries to set up and start
CA.
It doesn't:
# dig server..com
; DiG 9.8.1-RedHat-9.8.1-2.fc16 server..com
;; global
After upgrading FreeIPA from FC14/FreeIPAv1 to FC16/FreeIPAv2, secure
NFSv4 mounts do not work anymore. V2 is basically a reinstalled FreeIPA
server with user data migrated from v1, and host keys etc. recreated.
I get the following when trying to mount:
# mount -t nfs4 -o
On 11/16/2011 08:40 PM, Simo Sorce wrote:
Are you using DES keys ? In that case you probably need to allow weak
crypto on both server and client. Note that if all your server/clients
are FC16 and you have no old ones FC14 or RHEL 6 then you do not
need to force the creation of the nfs/
On 11/16/2011 08:27 PM, Rob Crittenden wrote:
Looks like https://bugzilla.redhat.com/show_bug.cgi?id=652273
Yes. For some reasons I always seem to end up with NFS problems...
The fix I used at that time IMO is no longer applicable... mozldap isn't
even installed anymore
Tom
On 11/16/2011 08:48 PM, Simo Sorce wrote:
If you did this on both server and client, then it looks like it is a
nfsd bug, and not a freeipa one.
So I filed a bug report against nfs-utils:
https://bugzilla.redhat.com/show_bug.cgi?id=754552
I hope Steve Dickson has some ideas...
Thanks,
Tom
On 11/16/2011 08:59 PM, Thomas Sailer wrote:
On 11/16/2011 08:48 PM, Simo Sorce wrote:
If you did this on both server and client, then it looks like it is a
nfsd bug, and not a freeipa one.
So I filed a bug report against nfs-utils:
https://bugzilla.redhat.com/show_bug.cgi?id=754552
Or maybe
Hi,
I've just upgraded from F16 to F18 and thus freeipa v3.1.2.
It basically works, on the command line. ipa user-show xxx works.
The Web UI however no longer works. I get the login window with Your
session has expired. Please re-login., no matter whether I use kerberos
or password login.
Thanks, John!
See the log below. The only thing that looks strange to me is
expiration_timestamp=1970-01-01T01:00:00. Where does this time come from?
Tom
[Tue Feb 05 16:16:53.798117 2013] [:error] [pid 6843] ipa: INFO: ***
PROCESS START ***
[Tue Feb 05 16:16:53.914486 2013] [:error] [pid
On 02/05/2013 06:32 PM, John Dennis wrote:
% ipactl status
# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-cad Service: RUNNING
ipa: INFO: The ipactl command was successful
Apparently, it isn't...
On 02/05/2013 06:47 PM, Petr Vobornik wrote:
Open Web Console in browser (in FF: 'Tools/Web Developer/Web Console',
in Chrome hit F12).
I'm using firefox. I'm getting a javascript warning about
getAttributeNode being deprecated, and some css complaints.
The first post just gets one's own
On 02/05/2013 08:02 PM, Rob Crittenden wrote:
Can you see if you have 60basev3.ldif in
/etc/dirsrv/slapd-YOUR-REALM/schema ?
That was indeed not there (only 60basev2.ldif).
I've copied it, restarted dirsrv.
ipa user-show admin works (it did work before though).
You'll want to look at
I have a few certificates that fail to be updated, for example the ldap
and http certificates. If I read the error message from getcert list
(see below) correctly, then the contents of the pinfiles are incorrect.
How do I fix this?
Thanks,
Tom
Number of certificates and requests being
Hi Rob,
thanks for the quick answer!
Does this work?
# ipa cert-show 1
I'm geussing it doesn't.
You're correct, it doesn't.
You are correct, the serial numbers didn't match.
I've fixed this, now I get the following error:
Request ID '2016140151':
status: CA_UNREACHABLE
I seem to be a victim of BZ 675742
I've fixed this, now I get the following error:
Request ID '2016140151':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed
at server. Certificate operation cannot be completed: FAILURE
(Profile
Great, thanks for the follow-up.
I was a bit too soon.
After sending the mail, I saw that the freeipa web GUI no longer worked.
It turned out that I ended up with two certificates with the name
Server-Cert in both the httpd and slapd certificate databases. It
doesn't seem to be possible
I've updated the machine running freeipa from f18 to f20.
Now I still have the old pki-base package
(pki-base-10.0.6-1.fc18.noarch). Trying to upgrade it results in the
following message:
error: lua script failed: [string
%pretrans(pki-base-10.1.0-1.fc20.noarch)]:22: Unable to upgrade to
On 12/29/2013 03:49 PM, Simo Sorce wrote:
Unfortunately you should have created the replica *before* the upgrade.
Too bad fedup didn't refuse to update and created this mess...
Have you tried downgrading all dogtag and tomcat packages to the fc18
ones ?
After some trial and error, I
Trying to install the replica on a Fedora 18 machine gives me a slightly
more verbose error message:
Unexpected error - see /var/log/ipareplica-install.log for details:
DatabaseError: Constraint violation: pre-hashed passwords are not valid
arguments: entry=cn=replication manager,cn=config:
Here's the corresponding log (from another attempt, thus the differing
timestamps) of the server slapd:
[09/Jan/2014:12:19:35 +0100] conn=375 fd=73 slot=73 connection from
a.b.c.d to e.f.g.h
[09/Jan/2014:12:19:35 +0100] conn=375 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
Hi Martin,
ipa config-mod --enable-migration=1
Thanks! I'm getting farther now.
It seems to manage setting up the main directory server, but fails
configuring the ca system.
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
After being unable to rescue my old freeipa installation, I installed a
new machine from scratch and imported the user data from the old
installation (so I could get rid of the separate PKI dirserv, too). That
worked fine.
Then I prepared a replica, and installed the replica on the old
On 01/17/2014 01:12 PM, Petr Spacek wrote:
On 17.1.2014 12:44, Thomas Sailer wrote:
# ldapsearch -Y GSSAPI \*
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified
GSS failure. Minor
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which
On 06/04/2015 04:33 PM, Rob Crittenden wrote:
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason
Am 25.06.2015 um 17:47 schrieb Simo Sorce:
Yes, the whole project is complex, but not because we like complexity,
it is complex because the problem space is complex and we are bound to
use existing protocols, which sometimes add in complexity, and we want
to offer useful features to admins, so
Hello everyone.
I upgraded a freeipa server from fedora 20 to fedora 22. It mostly
worked ok, but there are a few issues:
- pki-tomcat didn't start after the upgrade, and that in turn made
ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
had the wrong owner (root).
-
Martin, Rob, thanks for your answers!
On 06/01/2015 09:52 AM, Martin Basti wrote:
Could DS in chroot, cause the ipa-ldap-updater --upgrade cannot locate
the DS socket?
2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request.
I used fedup for the distro upgrade, so yes initially
37 matches
Mail list logo
