[Freeipa-users] replication mess
Hello,
we have 2 auth servers with a replication agreement. Turns out that auth-2
had network issues that went unnoticed from some time after a reboot. This
wasn't discovered until after a yum update on auth-1 this morning. Now my
logfile is filling up with this message:
[23/Mar/2017:10:33:58.923454036 -0400] NSMMReplicationPlugin - changelog
program - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): CSN
586175b00060 not found, we aren't as up to date, or we purged
I'm not quite sure how to proceed. auth-2 network was fixed, and yum
updated as well. Here are the replication error messages on auth-1 from
today. You can see where it came up after the yum update around 08:56, and
where auth-2 came up around 10:33.
[23/Mar/2017:08:56:13.006916824 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX.
Check if DB RUV needs to be updated
[23/Mar/2017:08:56:13.107849258 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca.
Check if DB RUV needs to be updated
[23/Mar/2017:08:56:17.107916747 -0400] NSMMReplicationPlugin -
agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth
failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:08:56:17.222567755 -0400] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind
with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:42:22.306319176 -0400] NSMMReplicationPlugin - ruv_compare_ruv:
the max CSN [58d3852e0060] from RUV [database RUV] is larger than the
max CSN [58d381ab0060] from RUV [changelog max RUV] for element
[{replica 96 ldap://auth-1.XXX:389} 585cae490060 58d3852e0060]
[23/Mar/2017:09:42:22.336995007 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: data for replica o=ipaca does not match
the data in the changelog. Recreating the changelog file. This could affect
replication with replica's consumers in which case the consumers should be
reinitialized.
[23/Mar/2017:09:42:54.126984585 -0400] NSMMReplicationPlugin -
agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth
failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:44:43.187606945 -0400] NSMMReplicationPlugin - changelog
program - _cl5NewDBFile: PR_DeleteSemaphore:
/var/lib/dirsrv/slapd-NETSEC/cldb/509e3886-c88911e6-bead9c0e-906bed50.sema;
NSPR error - -5943
[23/Mar/2017:09:45:13.525102119 -0400] NSMMReplicationPlugin - changelog
program - _cl5NewDBFile: PR_DeleteSemaphore:
/var/lib/dirsrv/slapd-NETSEC/cldb/f377a685-c8cb11e6-bead9c0e-906bed50.sema;
NSPR error - -5943
[23/Mar/2017:09:45:13.971420939 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX.
Check if DB RUV needs to be updated
[23/Mar/2017:09:45:14.024029592 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca.
Check if DB RUV needs to be updated
[23/Mar/2017:09:45:19.314736866 -0400] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind
with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:46:30.253821850 -0400] NSMMReplicationPlugin -
agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth
failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:48:39.269006200 -0400] NSMMReplicationPlugin - changelog
program - _cl5NewDBFile: PR_DeleteSemaphore:
/var/lib/dirsrv/slapd-NETSEC/cldb/509e3886-c88911e6-bead9c0e-906bed50.sema;
NSPR error - -5943
[23/Mar/2017:09:49:26.639767435 -0400] NSMMReplicationPlugin - changelog
program - _cl5NewDBFile: PR_DeleteSemaphore:
/var/lib/dirsrv/slapd-NETSEC/cldb/f377a685-c8cb11e6-bead9c0e-906bed50.sema;
NSPR error - -5943
[23/Mar/2017:09:49:26.762324568 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX.
Check if DB RUV needs to be updated
[23/Mar/2017:09:49:26.813931624 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca.
Check if DB RUV needs to be updated
[23/Mar/2017:09:49:37.397494832 -0400] NSMMReplicationPlugin -
agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth
failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:49:37.756217644 -0400] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind
with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:51:06.555004134 -0400] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind
with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()
[23/Mar/2017:09:51:06.616444861 -0400]
Re: [Freeipa-users] Getting error "Permission denied (publickey, gssapi-with-mic, password)" when running below ssh command
On Mon, 9 Jan 2017 10:55:05 +0100 Sumit wrote: SB> There are older reports that a similar audit message was triggered by SB> wrong SELinux labels on $HOME/.ssh and the files within. Although none SB> of the typical files in this directory are needed by GSSAPI SB> authentication it might worth to check. Does authentication work if you SB> temporally disable SELinux by calling 'setenforce 0' as root on the SB> command line? Or instead of disabling, fix the labels restorecon -rv ~/.ssh With -v restorecon will report if it changed any labels. or check for actual denials grep avc /var/log/audit/audit.log | grep ssh Robert -- Senior Software Engineer @ Parsons pgpjym51Kq_KZ.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] backing up and starting over...
On Thu, 22 Dec 2016 16:48:10 -0500 Robert wrote: RS> I tried to create a replica. It went well for the directory server, but RS> then: RS> RS> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 RS> seconds [1/27]: creating certificate server user RS> [2/27]: configuring certificate server instance RS> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure RS> CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned RS> non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: RS> CRITICAL See the installation logs and the following files/directories for RS> more information: ipa.ipaserver.install.cainstance.CAInstance: RS> CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration RS> failed. RS> [...] RS> So this looks like the culprit: RS> RS> [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Failed to contact master using admin portjavax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error So eventually I found proxy errors like this in a logfile: proxy_ajp:error (70007)The timeout specified has expired: I added large timeouts to /etc/httpd/conf.d/ipa-pki-proxy.conf Timeout 900 ProxyTimeout 900 This allowed my replica install to complete. However, when I logged in to the new replica, I was getting the same long timeout trying to load users. The error log had this: [Fri Dec 23 00:50:39.206858 2016] [proxy_ajp:error] [pid 31182] [client 10.71.10.118:49784] AH00896: failed to make connection to backend: localhost This started ringing a little bell in my head about localhost and ipv4 vs ipv6. I disabled ipv6 in /etc/sysctl.conf, and voila, users load in less than 5 seconds instead of 5 minutes or timing out. Hopefully this will also resolve the other weirdness I've been seeing. I'm keeping my fingers crossed. Robert -- Senior Software Engineer @ Parsons pgpqGB0jo68SB.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] backing up and starting over...
On Thu, 22 Dec 2016 09:25:52 +0100 Florence wrote:
FBR> you can find more information about backup and restore procedure in this
FBR> guide [1]. But, as stated in the documentation, the safest method would
FBR> rather be to install a replica [2].
FBR> [...]
FBR> [2]
FBR>
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html
I tried to create a replica. It went well for the directory server, but
then:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds [1/27]: creating certificate server user
[2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned
non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance:
CRITICAL See the installation logs and the following files/directories for
more information: ipa.ipaserver.install.cainstance.CAInstance:
CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration
failed.
from ipa-replica-install.log:
2016-12-22T21:00:53Z DEBUG Starting external process
2016-12-22T21:00:53Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ
2016-12-22T21:10:08Z DEBUG Process finished, return code=1
2016-12-22T21:10:08Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20161222160055.log
Loading deployment configuration from /tmp/tmpqYyqJJ.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Importing certificates from /tmp/ca.p12:
...
Import complete
---
Imported certificates in /etc/pki/pki-tomcat/alias:
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-cau,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
Installation failed:
Please check the CA logs in /var/log/pki/pki-tomcat/ca.
2016-12-22T21:10:08Z DEBUG stderr=
2016-12-22T21:10:08Z CRITICAL Failed to configure CA instance: Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned non-zero exit status 1
2016-12-22T21:10:08Z CRITICAL See the installation logs and the following
files/directories for more information:
2016-12-22T21:10:08Z CRITICAL /var/log/pki/pki-tomcat
2016-12-22T21:10:08Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
448, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
438, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
590, in __spawn_instance
DogtagInstance.spawn_instance(self, cfg_file)
File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 181, in spawn_instance
self.handle_setup_error(e)
File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 420, in handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.
2016-12-22T21:10:08Z DEBUG [error] RuntimeError: CA configuration failed.
2016-12-22T21:10:08Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318,
in run
cfgr.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310,
in run
self.execute()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332,
in execute
for nothing in self._executor():
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372,
in __runner
self._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394,
in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362,
in __runner
step()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359,
in
step = lambda: next(self.__gen)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81,
in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59,
in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 586,
in _configure
next(executor)
File
Re: [Freeipa-users] backing up and starting over...
On Thu, 22 Dec 2016 13:02:18 +0100 Martin wrote: MB> On 22.12.2016 09:25, Florence Blanc-Renaud wrote: MB> > On 12/21/2016 10:26 PM, Robert Story wrote: MB> >> I'm running a small instance of freeipa on CentOS 7 in our lab, for MB> >> about 20 MB> >> machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things MB> >> have gotten flaky. e.g. clicking on a user get the spinning 'Working' MB> >> dialog and can take 3-5 minutes to load the page. But often it will die MB> >> with 'internal error'. MB> MB> Could you check in /var/log/httpd/error_log what is it? MB> Does cli work well? ipa user-find Yes, cli works, and ldap mostly works, but not always. GUI works occasionally. Here's one: mod_wsgi (pid=6358): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. Traceback (most recent call last): File "/usr/share/ipa/wsgi.py", line 49, in application return api.Backend.wsgi_dispatch(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__ return self.route(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route return app(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 833, in __call__ self.create_context(ccache=ipa_ccache_name) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 123, in create_context self.Backend.ldap2.connect(ccache=ccache) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 205, in create_connection client_controls=clientctrls) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1108, in gssapi_bind '', auth_tokens, server_controls, client_controls) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler raise errors.DatabaseError(desc=desc, info=info) DatabaseError: Server is unwilling to perform: Too many failed logins. and this: ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials and ipa: ERROR: non-public: IOError: request data read error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 358, in wsgi_execute data = read_input(environ) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 195, in read_input return environ['wsgi.input'].read(length) IOError: request data read error rstory@EXAMPLE: None: IOError and AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' ipa: INFO: *** PROCESS START *** ipa: INFO: *** PROCESS START *** ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' while getting initial credentials [pid 3714] ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' while getting initial credentials [pid 3715] ipa: ERROR: release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_3714) != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/krb5ccache) ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'EXAMPLE') mod_wsgi (pid=3714): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. Traceback (most recent call last): File "/usr/share/ipa/wsgi.py", line 49, in application return api.Backend.wsgi_dispatch(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__ return self.route(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route return app(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 978, in __call__ self.kinit(user, self.api.env.realm, password, ipa_ccache_name) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 1010, in kinit raise CCacheError(message=unicode(e)) CCacheError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639068): Cannot contact any KDC for realm 'EXAMPLE' AH00170: caught SIGWINCH, shutting down gracefully and Script timed out before returning headers: wsgi.py, referer: https://auth-1.e
[Freeipa-users] backing up and starting over...
I'm running a small instance of freeipa on CentOS 7 in our lab, for about 20 machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things have gotten flaky. e.g. clicking on a user get the spinning 'Working' dialog and can take 3-5 minutes to load the page. But often it will die with 'internal error'. Is there a way to back up data so that I can re-install 4.4 and restore the data? Specifically users+uids/groups+gids, HBAC and sudo rules? Robert pgp0gh9zR2_U2.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] slow login with freeipa 4.2.0
On Mon, 25 Jul 2016 21:23:19 +0530 Rakesh wrote: RR> Hi, RR> RR> I am facing slow login issue with IPA 4.2.0 version. The login takes around RR> 18-19s Any change that it's running on a VM? If so, check your entropy: cat /proc/sys/kernel/random/entropy_avail If it's low (like < 1k), install haveged. Robert -- Senior Software Engineer @ Parsons pgperPRYfkDAd.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] disaster recovery
On Mon, 27 Jun 2016 08:59:14 -0400 Robert wrote: RS> On Mon, 27 Jun 2016 08:09:59 +0200 Martin wrote: RS> MB> On 26.06.2016 08:17, Robert Story wrote: RS> MB> > Hello, RS> MB> > RS> MB> > I was running a single ipa instance on Centos 7 for a small lab RS> MB> > (ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64), and the disk was corrupted. RS> MB> > I have a (mostly) full backup (/var/log/ and /var/run/ excluded), which I RS> MB> > restored. ipa server didn't start, and wanted me to run RS> MB> > ipa-server-upgrade. This failed, and I see this in the log: RS> MB> > [...] RS> MB> Hello, upgrader refuses to upgrade because check which requires RS> MB> /var/lib/ipa failed. Upgrader thinks that IPA is not installed. RS> MB> RS> MB> So are you sure you have backup of /var/lib/ipa ? RS> RS> Yep, /var/lib/ipa is there: RS> RS> ls -lR RS> [...] RS> ./pki-ca/publish: RS> total 0 RS> lrwxrwxrwx. 1 pkiuser pkiuser 57 Jun 24 21:00 MasterCRL.bin -> /var/lib/ipa/pki-ca/publish/MasterCRL-20160624-21.der RS> RS> RS> Looking through the backups, I see that there are no MasterCRL files from RS> the 25th (the backup I restored), but a bunch from the 24th, so maybe I RS> need to try another restore with files from then... So restoring /var/lib/ipa didn't work, and restoring the whole VM is taking way to long. I have a new VM up with a new ipa-server install, and am wondering if there is a way to import the data from the old filesystem? Robert -- Senior Software Engineer @ Parsons pgpWdQ3DBFr2R.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] disaster recovery
On Mon, 27 Jun 2016 08:09:59 +0200 Martin wrote:
MB> On 26.06.2016 08:17, Robert Story wrote:
MB> > Hello,
MB> >
MB> > I was running a single ipa instance on Centos 7 for a small lab
MB> > (ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64), and the disk was
corrupted.
MB> > I have a (mostly) full backup (/var/log/ and /var/run/ excluded), which I
MB> > restored. ipa server didn't start, and wanted me to run
MB> > ipa-server-upgrade. This failed, and I see this in the log:
MB> >
MB> > 2016-06-25T23:16:37Z DEBUG Mounting ipaserver.rpcserver.jsonserver_kerb()
at '/json'
MB> > 2016-06-25T23:16:37Z DEBUG session_auth_duration: 0:20:00
MB> > 2016-06-25T23:16:37Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
MB> > 2016-06-25T23:16:37Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
MB> > return_value = self.run()
MB> >File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 47, in run
MB> > server.upgrade_check(self.options)
MB> >File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line
1573, in upgrade_check
MB> > sys.exit(1)
MB> >
MB> > 2016-06-25T23:16:37Z DEBUG The ipa-server-upgrade command failed,
exception: SystemExit: 1
MB> >
MB> >
MB> > I tried starting dirsrv@DOMAIN manually, and I get thisin the dirsrv log:
MB> >
MB> >
MB> > [26/Jun/2016:01:46:54 -0400] - 389-Directory/1.3.4.0 B2016.175.1716
starting up
MB> > [26/Jun/2016:01:46:54 -0400] - WARNING: changelog: entry cache size
2097152B is less than db size 143196160B; We recommend to increase the entry
cache size nsslapd-cachememsize.
MB> > [26/Jun/2016:01:46:54 -0400] - Detected Disorderly Shutdown last time
Directory Server was running, recovering database.
MB> > [26/Jun/2016:01:46:55 -0400] - libdb: BDB2506 file userRoot/id2entry.db
has LSN 4336/2969724, past end of log at 1/176
MB> > [26/Jun/2016:01:46:56 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
MB> > [26/Jun/2016:01:46:56 -0400] - libdb: BDB2508 to another without clearing
the database LSNs, or by removing all of
MB> > [26/Jun/2016:01:46:56 -0400] - libdb: BDB2509 the log files from a
database environment
MB> > [26/Jun/2016:01:46:57 -0400] - dbp->open("userRoot/id2entry.db") failed:
Invalid argument (22)
MB> > [26/Jun/2016:01:46:57 -0400] - dblayer_instance_start fail: Invalid
argument (22)
MB> > [26/Jun/2016:01:46:57 -0400] - libdb: BDB2506 file ipaca/id2entry.db has
LSN 4336/2990140, past end of log at 1/288
MB> > [26/Jun/2016:01:46:57 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
MB> > [26/Jun/2016:01:46:57 -0400] - libdb: BDB2508 to another without clearing
the database LSNs, or by removing all of
MB> > [26/Jun/2016:01:46:57 -0400] - libdb: BDB2509 the log files from a
database environment
MB> > [26/Jun/2016:01:46:57 -0400] - dbp->open("ipaca/id2entry.db") failed:
Invalid argument (22)
MB> > [26/Jun/2016:01:46:58 -0400] - dblayer_instance_start fail: Invalid
argument (22)
MB> > [26/Jun/2016:01:46:58 -0400] - libdb: BDB2506 file changelog/id2entry.db
has LSN 4336/2921967, past end of log at 1/288
MB> > [26/Jun/2016:01:46:58 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
MB> > [26/Jun/2016:01:46:58 -0400] - libdb: BDB2508 to another without clearing
the database LSNs, or by removing all of
MB> > [26/Jun/2016:01:46:58 -0400] - libdb: BDB2509 the log files from a
database environment
MB> > [26/Jun/2016:01:46:58 -0400] - dbp->open("changelog/id2entry.db") failed:
Invalid argument (22)
MB> > [26/Jun/2016:01:46:58 -0400] - dblayer_instance_start fail: Invalid
argument (22)
MB> > [26/Jun/2016:01:46:58 -0400] - start: Failed to start databases, err=22
Invalid argument
MB> >
MB> >
MB> > So I'm trying to figure out if I can salvage this restored VM, or if I
need
MB> > to reinstall from scratch; and if I do reinstall, am I going to be able to
MB> > restore my old data somehow. I have a funny feeling that there are
MB> > important files in /var/log and/or /var/run and I'm up the creek without a
MB> > paddle.
MB> >
MB> > And yes, once I have a working system again I'm going to set up a replica
MB> > to help avoid this mess in the future.
MB> >
MB> > Robert
MB> >
MB> >
MB> >
MB>
MB> Hello, upgrader refuses to upgrade because check which requires
MB> /var/lib/ipa failed. Upgrader thinks that IPA is not installed.
MB>
MB> So are you sure you have
[Freeipa-users] disaster recovery
Hello,
I was running a single ipa instance on Centos 7 for a small lab
(ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64), and the disk was corrupted.
I have a (mostly) full backup (/var/log/ and /var/run/ excluded), which I
restored. ipa server didn't start, and wanted me to run
ipa-server-upgrade. This failed, and I see this in the log:
2016-06-25T23:16:37Z DEBUG Mounting ipaserver.rpcserver.jsonserver_kerb() at
'/json'
2016-06-25T23:16:37Z DEBUG session_auth_duration: 0:20:00
2016-06-25T23:16:37Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2016-06-25T23:16:37Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 47, in run
server.upgrade_check(self.options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1573, in upgrade_check
sys.exit(1)
2016-06-25T23:16:37Z DEBUG The ipa-server-upgrade command failed, exception:
SystemExit: 1
I tried starting dirsrv@DOMAIN manually, and I get thisin the dirsrv log:
[26/Jun/2016:01:46:54 -0400] - 389-Directory/1.3.4.0 B2016.175.1716 starting up
[26/Jun/2016:01:46:54 -0400] - WARNING: changelog: entry cache size 2097152B is
less than db size 143196160B; We recommend to increase the entry cache size
nsslapd-cachememsize.
[26/Jun/2016:01:46:54 -0400] - Detected Disorderly Shutdown last time Directory
Server was running, recovering database.
[26/Jun/2016:01:46:55 -0400] - libdb: BDB2506 file userRoot/id2entry.db has LSN
4336/2969724, past end of log at 1/176
[26/Jun/2016:01:46:56 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
[26/Jun/2016:01:46:56 -0400] - libdb: BDB2508 to another without clearing the
database LSNs, or by removing all of
[26/Jun/2016:01:46:56 -0400] - libdb: BDB2509 the log files from a database
environment
[26/Jun/2016:01:46:57 -0400] - dbp->open("userRoot/id2entry.db") failed:
Invalid argument (22)
[26/Jun/2016:01:46:57 -0400] - dblayer_instance_start fail: Invalid argument
(22)
[26/Jun/2016:01:46:57 -0400] - libdb: BDB2506 file ipaca/id2entry.db has LSN
4336/2990140, past end of log at 1/288
[26/Jun/2016:01:46:57 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
[26/Jun/2016:01:46:57 -0400] - libdb: BDB2508 to another without clearing the
database LSNs, or by removing all of
[26/Jun/2016:01:46:57 -0400] - libdb: BDB2509 the log files from a database
environment
[26/Jun/2016:01:46:57 -0400] - dbp->open("ipaca/id2entry.db") failed: Invalid
argument (22)
[26/Jun/2016:01:46:58 -0400] - dblayer_instance_start fail: Invalid argument
(22)
[26/Jun/2016:01:46:58 -0400] - libdb: BDB2506 file changelog/id2entry.db has
LSN 4336/2921967, past end of log at 1/288
[26/Jun/2016:01:46:58 -0400] - libdb: BDB2507 Commonly caused by moving a
database from one database environment
[26/Jun/2016:01:46:58 -0400] - libdb: BDB2508 to another without clearing the
database LSNs, or by removing all of
[26/Jun/2016:01:46:58 -0400] - libdb: BDB2509 the log files from a database
environment
[26/Jun/2016:01:46:58 -0400] - dbp->open("changelog/id2entry.db") failed:
Invalid argument (22)
[26/Jun/2016:01:46:58 -0400] - dblayer_instance_start fail: Invalid argument
(22)
[26/Jun/2016:01:46:58 -0400] - start: Failed to start databases, err=22 Invalid
argument
So I'm trying to figure out if I can salvage this restored VM, or if I need
to reinstall from scratch; and if I do reinstall, am I going to be able to
restore my old data somehow. I have a funny feeling that there are
important files in /var/log and/or /var/run and I'm up the creek without a
paddle.
And yes, once I have a working system again I'm going to set up a replica
to help avoid this mess in the future.
Robert
--
Senior Software Engineer @ Parsons
pgpqjqKpupzeO.pgp
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA vulnerability management SSL
On Fri, 29 Apr 2016 08:56:57 -0700 Sean wrote: SH> Hi Rob, SH> SH> I stopped IPA, modified dse.ldif, restarted with the cipher list and it SH> started without issue Just thought I'd point out the other recent thread, "freeipa update changed my cipher set", which mentions that dse.ldif can get reset on upgrades, along with a way to make persistent overrides. Robert -- Senior Software Engineer @ Parsons pgpLWRPcD_Jhb.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Another CentOS 6.x to CentOS 7.1 migration question
I've followed the migration document https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html almost to the end. I'm at step 10, which stops everything on the old . My concern is all the installed servers that are pointing at the old system. That host name is hardcoded in sssd.conf all over my network, and we rely on freeIPA for centralized user management and ssh keys. My original system was auth.example, and the new one is auth-2.example. Is it safe to make auth.example a CNAME to auth-2.example? Or will something somewhere break if the ip address changes (and is pointing at a newer version of freeIP)? Robert -- Senior Software Engineer @ Parsons pgpazBmvVuR3Z.pgp Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Mountain Lion GUI Login (Expired passwords / Mavericks too)
On Thu, 13 Mar 2014 14:08:29 + Jason wrote: JW Now if I create a new user in IPA. It will require a password change on JW logon. JW JW When I logon on the Mac with this new user. The password box wiggles JW and a box appears underneath it. Reset your password. Saying I need JW to set a new password. So I enter a new password and I verify it. Then JW I click Reset Password and it wiggle... no matter how many times I JW try, it doesn't move on. I don't have OS X, but every time I create a new test user on linux and log in to test it, I get bit by the fact that the passwd change always asks for the existing password first, before asking for the new password. So I have to enter the original password once to login, once to make passwd happy, and then enter the new password. Are you sure the dialog box isn't asking for the existing password first? Robert -- Senior Software Engineer @ Parsons signature.asc Description: PGP signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
On Mon, 10 Mar 2014 16:07:54 -0400 Simo wrote: SS Unfortunately I've already scrapped that install and just went with SS the internal self-signed CA. So far, the only annoyance is that the SS webserver also presents a self-signed cert for the UI. Is it safe to SS replace just the web cert with a cert signed by my local CA? Or might SS that break something? SS SS Import the CA cert in your browser. This is exactly what I'm trying to avoid. Users already have to install our corporate CA cert, and I'd like to avoid having to install two. I'm hoping that the cert for the UI could be swapped for one signed by our existing CA. Robert -- Senior Software Engineer @ Parsons signature.asc Description: PGP signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
On Mon, 10 Mar 2014 15:44:01 +0100 Jan wrote: JC On 6.3.2014 05:42, Robert Story wrote: JC I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64) JC and an external CA. I'm getting this error: JC [snip] JC Can you please run certutil -V on the issuer certificate JC (CN=Certificate Authority,O=xxx)? That might give us a clue why it is JC invalid. Unfortunately I've already scrapped that install and just went with the internal self-signed CA. So far, the only annoyance is that the webserver also presents a self-signed cert for the UI. Is it safe to replace just the web cert with a cert signed by my local CA? Or might that break something? Robert -- Senior Software Engineer @ Parsons signature.asc Description: PGP signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] install with external CA failed
Hi, I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64) and an external CA. I'm getting this error: Command '/usr/bin/sslget -v -n ipa-ca-agent -p -d /tmp/tmp-jNYt3P -r /ca/agent/ca/profileReview?requestId=6 auth.lan:9443' returned non-zero exit status 4 I found a thread from back in 2012 with exact same symptoms: https://www.redhat.com/archives/freeipa-users/2012-May/msg00357.html Unfortunately, the thread died out without any resolution/fix. When I run the suggested commands from that thread, I get the same results the OP did.. #certutil -L -d /tmp/tmp-jNYt3P/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ipa-ca-agent u,u,u Certificate Authority - xxx CT,C,C testnick P,, xxx Certificate Authority - xxxCT,C,C # certutil -V -u C -n ipa-ca-agent -d /tmp/tmp-jNYt3P/ certutil: certificate is invalid: Issuer certificate is invalid. # certutil -L -n ipa-ca-agent -d /tmp/tmp-jNYt3P/ Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=xxx Validity: Not Before: Thu Mar 06 04:17:13 2014 Not After : Wed Feb 24 04:17:13 2016 Subject: CN=ipa-ca-agent,O=xxx Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: bf:0c:5b:f0:14:9e:0f:26:91:21:66:62:95:0c:4d:04: e5:ec:96:6f:a1:3b:a8:05:de:1b:40:a7:7c:59:55:c4: 1e:a0:62:3d:7a:50:e8:c4:8b:d7:5d:cd:55:b2:e7:f9: 63:f6:43:75:1e:3d:3c:ac:51:a4:81:94:6b:e5:7f:94: d7:b2:aa:8d:e8:b6:50:f2:24:96:76:8d:5f:e9:aa:43: 07:97:c8:06:2e:dc:22:9b:d1:2e:90:24:d8:07:94:33: d1:0f:44:e5:14:37:3c:96:ee:24:e0:07:91:f1:ee:c8: c4:01:e9:85:d8:35:eb:42:92:8a:58:c3:ae:e8:7d:27: 4d:2d:cb:b8:97:0b:5d:e0:3c:99:8a:a8:a2:b7:e2:10: 61:2b:77:33:87:ea:59:16:87:f7:f7:43:cf:c2:7b:60: 3a:fc:44:2f:9e:9c:56:bc:99:0c:d0:e9:08:d6:db:f5: b1:d2:5e:28:45:d2:8f:71:1d:49:e9:41:c6:d2:e0:03: ac:85:ea:51:c6:17:5d:ed:eb:a5:11:86:40:37:cf:49: d3:cc:11:f1:3f:17:61:38:52:fa:12:a6:a0:bf:61:74: aa:3e:87:bd:ff:d1:eb:d7:c5:d7:d5:90:8f:d6:d6:e1: ab:d0:1f:db:91:8e:ff:d1:52:e3:6a:7a:fe:20:b3:53 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: b5:5e:45:9f:e9:71:c5:11:a2:6c:6c:06:00:be:02:ad: 8e:ae:76:1b Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: http://auth.lan:80/ca/ocsp; Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Client Authentication Certificate E-Mail Protection Certificate Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 91:e8:3c:26:1e:e6:24:35:64:95:92:10:79:9b:c3:3f: 3d:6c:7b:db:56:bd:98:85:31:4a:2c:6c:1f:76:e4:74: 8a:90:49:43:6d:16:63:f9:cc:9b:89:bd:bc:5c:fa:3b: 55:9e:a8:54:ce:61:fa:62:61:cf:b5:47:54:e5:70:f6: d0:a0:a6:56:bf:1e:19:4d:f3:95:8a:70:1f:43:c2:6b: 85:bf:dd:90:6a:13:f7:58:9d:b2:40:88:d6:3a:d1:84: 2e:7f:b8:b8:e1:f9:5f:83:c5:d4:55:c4:a7:1a:28:a4: 64:fc:ac:78:3b:43:a0:00:78:db:f1:cc:a6:b6:11:70: 64:2f:43:d2:74:a5:2a:50:91:e0:8d:8c:82:c5:1a:5c: dd:00:60:62:55:be:0a:ea:b9:75:0f:8d:0e:40:cd:26: 9c:63:08:3f:7d:79:c5:6b:73:fd:26:60:d3:e4:59:1e: 1d:0f:82:ea:eb:23:b3:b4:59:7f:a9:87:e8:01:c7:aa: 7b:c0:dd:0a:f0:4d:da:90:c9:57:00:4b:86:ea:58:22: ff:45:11:18:25:de:09:ee:a4:7a:4a:ea:8f:17:c9:ad: 38:15:af:fa:c0:f3:fb:1c:6c:e1:69:1f:99:4e:fe:a2: eb:66:92:77:3a:5d:8f:7a:63:9b:14:ea:95:3e:c7:e9 Fingerprint (MD5): 96:68:7A:76:9F:06:78:BC:67:85:0C:82:A8:43:14:6B Fingerprint (SHA1): 99:7D:9F:1B:F4:A7:52:9F:CF:BF:23:4F:5B:1A:90:22:19:14:37:16 Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: User ... and so on... Any suggestions from anyone who has gotten an external-ca install to work? Robert -- Senior Software Engineer @ Parsons
