Re: [Freeipa-users] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Standa Laznicka]

On 05/04/2017 02:01 PM, Chris Dagdigian wrote:


Florence Blanc-Renaud wrote:

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766



Thanks Flo, I agree that this looks like the issue I"m hitting in v4.4 
much appreciated!


I'm gonna be watching this closely, it's nerve wracking knowing that I 
can't use, update or create *any* replica servers at the moment ...


-Chris


You can, but you probably won't be able to install a CA replica on them 
(you have to leave out the --setup-ca option). In the meantime, you can 
create replicas without CA replication and when the Dogtag/DS guys solve 
the problem, you can run ipa-ca-install on those to setup CA replication 
there as well.
-- 
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] Migration from FreeIPA 3.0 to 4.x

[Standa Laznicka]

While I don't consider myself an expert, I should note that 
ipa-replica-prepare has not been deprecated. The proposed solution to 
follow


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.html

is indeed the correct one.

Not to be confused about ipa-replica-prepare: this command shall not be 
used on domain level 1 machines since the replication is
solved in a smarter and more automatic way. The command would not work 
on domain level 1 anyway.


HTH,
Standa

On 03/24/2017 11:58 AM, Christophe TREFOIS wrote:
I’m not expert but I think ipa-replica-prepare is depcrecated in 4.4 
as the procedure become more simple.


I think setting up a new cluster of CentOS 7.3 machines and setting up 
replicas against the old cluster is sufficient.


What do the experts say?

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T:+352 46 66 44 6124
F:+352 46 66 44 6949
http://www.uni.lu/lcsb

Facebook Twitter 
Google Plus 
Linkedin 
skype 




This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the 
original message and any copies.




On 24 Mar 2017, at 00:54, Zak Peirce > wrote:


I am looking to take this same journey.  I found this guide, it seems 
like

it covers all the bases

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h
tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h
tml


-Zak

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dagan
Sent: Thursday, March 23, 2017 3:52 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x

Hi,

I am hoping someone will be able to help answer some questions about
migrations.

I have been asked to look at upgrading an existing FreeIPA 
installation on

CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent stable
release (4.4.0).

The existing CentOS 6 installation does not manage DNS or have a CA that
is being used (though the may be installed. It's primarily for user
authentication and user group management.

There are only a small number of users, groups, and hosts to migrate -
less than 100 of each.
But the data is used for LDAP integration in various applications so it
needs to be consistent.

Would it be recommended to do a straight LDIF type export and import of
the data, and configure the new FreeIPA installation for the new
access/sudo rules?

Would that risk leaving behind any data I would need to know about?

We are planning to review the sudo rules, host access lists etc as 
part of

the migration work. So leaving behind some data may not be a blocker to
upgrade.

Any suggestions or links welcome.

Cheers,
Dagan McGregor




--
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

--
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






-- 
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] Authenticating windows users

[Standa Laznicka]

I changed the text emphasis so that this is more clear in the future, 
thanks for noticing.


On 03/23/2017 07:52 PM, Jason B. Nance wrote:


Thanks Jason, but those documents need AD as the primary
authenticator. This is not the case for us.

I think you need to read them a bit closer.  Very first line of first 
link says:


"This article describes direct integration between FreeIPA and Windows 
machine, i.e. without involving Active Directory server."




On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance
mailto:ja...@tresgeek.net>> wrote:

We are primarily linux/osx shop and we currently have
FreeIPA/IDM (ver 4.2) as our master. I will need to add a
handful of windows machines and been trying to figure out
how to authenticate our windows users with FreeIPA/IDM. Is
this even possible? I know Global Catalogs may not happen
anytime soon (sad face).  I'm open to -all- ideas, even if
it is a paid solution (not sure if centrify and the likes
can sync up to FreeIPA/IDM).

I would start here:

https://www.freeipa.org/page/Windows_authentication_against_FreeIPA


https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step








-- 
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] Manual Cleanup

[Standa Laznicka]

Hello Ian,

You could do:
`ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup`

Then you may need to check again for the master with `ipa-replica-manage 
list`. If it's not there anymore, check whether some RUVs are still in 
place with `ipa-replica-manage list-ruv`.


The last command should get you RUVs on both CA and domain suffixes if 
you're using FreeIPA >= 4.3.2 (hope I got the .z number right). If you 
see that there's some RUVs left for the wrong host, try calling 
`ipa-replica-manage clean-ruv ` which should remove the RUV (no 
matter the suffix - CA or domain - just give it the number and it should 
work given FreeIPA >= 4.3.2 is used).


HTH,
Standa

On 03/16/2017 07:14 PM, Ian Harding wrote:

I've made some progress.  But I have one zombie replication agreement to
kill, I just don't know the syntax.

freeipa-dal.bpt.rocks does not exist.  I want all references to it to go
away.

How would I do that with ldapmodify?

Thanks!


[root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch  -D "cn=directory
manager" -w ... -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
nscpentrywsi
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter:
(&(objectclass=nstombstone)(nsUniqueId=---))
# requesting: nscpentrywsi
#

# replica, o\3Dipaca, mapping tree, config
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: cn: replica
nscpentrywsi: createTimestamp: 20160814234939Z
nscpentrywsi: creatorsName: cn=directory manager
nscpentrywsi: modifiersName: cn=Multimaster Replication
Plugin,cn=plugins,cn=c
  onfig
nscpentrywsi: modifyTimestamp: 20170316181544Z
nscpentrywsi: nsDS5Flags: 1
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
cloneAgreement1-freei
  pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-free
  ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-seat
  tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaId: 1065
nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1
nscpentrywsi: nsDS5ReplicaRoot: o=ipaca
nscpentrywsi: nsDS5ReplicaType: 3
nscpentrywsi: nsState::
KQQAAABO1spYKg
  ==
nscpentrywsi: nsds5replicabinddngroup: cn=replication
managers,cn=sysaccounts,
  cn=etc,dc=bpt,dc=rocks
nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: nsDS5Replica
nscpentrywsi: objectClass: extensibleobject
nscpentrywsi: numSubordinates: 2
nscpentrywsi: nsds50ruv: {replicageneration} 57c291d90429
nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57f84
  0bf0429 58cad6670429
nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389}
nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389}
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p
  ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p
  ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsruvReplicaLastModified: {replica 1065
ldap://freeipa-sea.bpt.r
  ocks:389} 58cad63d
nscpentrywsi: nsruvReplicaLastModified: {replica 1290
ldap://seattlenfs.bpt.ro
  cks:389} 
nscpentrywsi: nsruvReplicaLastModified: {replica 1295
ldap://freeipa-dal.bpt.r
  ocks:389} 
nscpentrywsi: nsds5ReplicaChangeCount: 15993
nscpentrywsi: nsds5replicareapactive: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del
freeipa-dal.bpt.rocks --forceDirectory Manager password:

'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: master
freeipa-sea.bpt.rocks: master
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
freeipa-sea.bpt.rocks
seattlenfs.bpt.rocks: replica
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list
Directory Manager password:

seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: CA not configured
freeipa-sea.bpt.rocks: master



--
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-replica-conncheck wants listener on port 7389

[Standa Laznicka]

On 02/28/2017 09:59 AM, Tomas Krizek wrote:

On 02/27/2017 11:24 PM, Ian Pilcher wrote:

I'm part way through my CentOS 6 to 7 "upgrade".  I've reached the
point of trying to set up my new IPA server as a replica of a temporary
VM.

ipa-replica-conncheck is complaining, because nothing on the temporary
server is listening on port 7389.

The documentation here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html


Says:

   In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not
   required.

Which seems to indicate that nothing *should* be listening on that port
on a CentOS 7 IPA server.

So who's right?  And if something (pki-tomcatd?) should be listening on
that port, how do I make it do so?

Thanks!


On a CentOS 7 IPA server, port 7389 should not be required. You can
bypass the check with --skip-conncheck when running ipa-replica-install.



Please, rather check what the problem is. Port 7389 is not required for 
the newer system, but the old 6.x system has to be listening on it so 
that we can replicate agains the older Dogtag database. From the 
previous mail I believe you were following the right documentation, 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc, 
correct?
-- 
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] New install, unsupported format?

[Standa Laznicka]

On 02/27/2017 04:51 PM, Steve Huston wrote:

On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka  wrote:

Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can
run `ipa domainlevel-get` on the master if you don't know)? Did you have a
client installed prior to ipa-replica-install?

It's level 1.  I did have a couple clients installed, and the machine
I was trying to promote to a replica was one of them.  This whole
instance is a testing instance, with live data but not in production,
while I make sure everything works as expected before I deploy it, so
the servers and their data are new as of a couple weeks ago and began
life as a RHEL7.3 install.

It seems there might be two issues here; the one I originally reported
was that the ipa-server packages installed on a client machine are
unable to talk to the server, even though it obviously knows what the
server is (the "unsupported format" error I originally shared).  The
second is with setting up a replica in general.
The server rpm packages should have no impact on client settings if 
neither server nor replica are installed on the given machine. IIRC 
client only uses the NSS database in /etc/ipa/nssdb, you may want to 
check the permissions there (should be o+xr for the folder, o+r for the 
*.db files there).

I had tried the various methods outlined in the RedHat IdM
documentation, including promoting a client via an administrators TGT,
adding the client to the ipaservers group on the server, etc.  What
did finally work was unprovisioning the client, setting a one-time
password, and running "ipa-replica-install -v
--domain=astro.princeton.edu --server=ipa.astro.princeton.edu
--realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu
--setup-ca -p foobar" - this yielded a fully working replica when it
finished.  All of the previous failures happened in the same way as
mentioned before - it seems to unprovision the client for some reason,
then fail in reprovisioning it.
I believe your machine might have been in some kind of undecided state 
when you tried to promote a client to a replica. What happens during 
replica installation on domain level 1 is that client installation is 
checked first. If client is installed the installation continues with 
other steps, if it's not, it tries to install the client.
In your case, you probably had your client installed at first and tried 
to install replica. Something bad happened, can't be sure what, the 
installation failed and tried to uninstall the client but that might 
have failed, too. Eventually, you uninstalled the client yourself 
successfully, all files were removed and its records were also removed 
from the server. This made it possible to eventually successfully 
install a replica.
I wouldn't bet my life on it but I'd think the installation could have 
gone successfully even if you installed a client and tried to promote it 
again :)


Anyway, I am sorry to hear you had such troubles, the replica 
installation is not usually such a painful process, I hope you will have 
more luck with FreeIPA in the future.

One problem which has cropped up before and caused problems is with
DNS capitalization.  DNS reports the domain name of "Princeton.EDU"
for hosts here, which means in order to do just about anything with a
FreeIPA server I have to manually add the host to /etc/hosts with all
lowercase letters.  I also have to force all of the host names via
command line switches so that DNS is not consulted for lookups, which
will return the StudlyCaps names and fail.  I suppose I should raise
that as a separate issue, because my understanding is that
hostnames/domainnames should be case insensitive so I'm not sure why
FreeIPA cares (and it may be easier to steer the entire project to not
care than convince those in control of DNS here to change it :D )



--
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] New install, unsupported format?

[Standa Laznicka]

On 02/24/2017 08:38 PM, Steve Huston wrote:

So, I tried a different tack.  Took my bare VM configured as an IPA
client, did a 'yum install ipa-server' and edited the cainstance.py
file to fix the IPv6 issue.  Then, without adding the host to
ipaservers in the webui, I simply tried to promote it:

# kinit admin
Password for ad...@astro.princeton.edu:
# ipa-replica-install --verbose
ipa.ipapython.install.cli.install_tool(Replica): DEBUGLogging to
/var/log/ipareplica-install.log
ipa.ipapython.install.cli.install_tool(Replica): DEBUG
ipa-replica-install was invoked with arguments [] and options:
{'no_dns_sshfp': None, 'skip_schema_check': None, 'setup_kra': None,
'ip_addresses': None
, 'mkhomedir': None, 'http_cert_files': None, 'ssh_trust_dns': None,
'reverse_zones': None, 'no_forwarders': None, 'keytab': None,
'no_ntp': None, 'domain_name': None, 'http_cert_name': None,
'dirsrv_cert_files
': None, 'no_dnssec_validation': None, 'no_reverse': None,
'unattended': False, 'auto_reverse': None, 'auto_forwarders': None,
'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None,
'dirsrv_config_file':
  None, 'forwarders': None, 'verbose': True, 'setup_ca': None,
'realm_name': None, 'skip_conncheck': None, 'no_ssh': None,
'forward_policy': None, 'dirsrv_cert_name': None, 'quiet': False,
'server': None, 'setup_dns': None, 'host_name': None, 'log_file':
None, 'allow_zone_overlap': None}
ipa.ipapython.install.cli.install_tool(Replica): DEBUGIPA version
4.4.0-14.el7_3.4
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/selinuxenabled
ipa : DEBUGProcess finished, return code=0
ipa : DEBUGstdout=
ipa : DEBUGstderr=
ipa : DEBUGLoading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
ipa : DEBUGLoading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
ipa : DEBUGhttpd is not configured
ipa : DEBUGkadmin is not configured
ipa : DEBUGdirsrv is not configured
ipa : DEBUGpki-tomcatd is not configured
ipa : DEBUGinstall is not configured
ipa : DEBUGkrb5kdc is not configured
ipa : DEBUGntpd is not configured
ipa : DEBUGnamed is not configured
ipa : DEBUGipa_memcached is not configured
ipa : DEBUGfilestore is tracking no files
ipa : DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa : DEBUGConfiguring client side components
Configuring client side components
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/ipa-client-install --unattended --no-ntp
IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using
'ipa-client-install --uninstall'.
ipa : DEBUGProcess finished, return code=3
Removing client side components
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/ipa-client-install --unattended
--uninstall
Unenrolling client from IPA server
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
nslcd daemon is not installed, skip configuration
Client uninstall complete.
ipa : DEBUGProcess finished, return code=0

ipa.ipapython.install.cli.install_tool(Replica): 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 308, in run
 self.validate()
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 317, in validate
 for nothing in self._validator():
   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 564, in _configure
 next(validator)
   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 372, in __runner
 self._handle_exception(exc_info)
   File "/usr/lib/pytho

Re: [Freeipa-users] New install, unsupported format?

[Standa Laznicka]

Hello,
I don't quite understand your situation - have the error happened during 
an addition of the host to the "ipaservers" group or during replica 
installation?


Certutil is a wonderful piece of software that returns 
"(SEC_ERROR_LEGACY_DATABASE)" in about 90% of most common cases but I 
have never seen an actual legacy database. Usually, this error means 
that the directory you're pointing the certutil tool to either does not 
exist or you don't have the permissions to read/write in this exact 
directory.


Cheers,
Standa

P.S.: I might have sent you this email twice because I am a bad person 
when it comes to the "Send" button, please reply to the email which has 
"freeipa-users" in CC :)


On 02/23/2017 10:38 PM, Steve Huston wrote:

I already had to do that previously to get other things to work; I had
solved it by changing line 582 of
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from
"::1" to "localhost" before installing the server.  I did do this on
the to-be-promoted client as well, to no avail.

On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden  wrote:

Steve Huston wrote:

Next stage of my testing was to make a replica of the FreeIPA server,
and I started by doing a 'yum install ipa-server' and then moved on to
adding the host to the ipaservers group.  This fails every time
however, with the error:

ipa: ERROR: cannot connect to
'https://ipa.astro.princeton.edu/ipa/json':
(SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
unsupported format.

Searches on this seem to turn up things like expired certificates, or
"reboot httpd" (I went ahead and rebooted the whole ipa server), but
nothing concrete.  Suggestions?  Everything (server and soon-to-be
replica) running RHEL7.3 with all updates.


See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9

rob





--
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] FreeIPA 4.3.1 ipa-replica-install wrong exit code?

[Standa Laznicka]

On 02/23/2017 08:30 AM, Martin Basti wrote:


On 23.02.2017 00:17, Diogenes S. Jesus wrote:
We are ansible-playbooking FreeIPA and we don't want to care about if 
freeipa is installed, we just want to ignore errors if it already is 
- but for that the exit code is relevant.
Either the return code is wrong in the code or in the manual - 
according to the manual, it should be 3, but it's currently 1.



ubuntu@ipa02:~$ sudo -i
root@ipa02:~# http_proxy='' https_proxy='' ipa-replica-install 
--dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx 
--http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export 
--http-pin=export
ipa.ipapython.install.cli.install_tool(Replica): ERROR  IPA server is 
already configured on this system.
If you want to reinstall the IPA server, please uninstall it first 
using 'ipa-server-install --uninstall'.
ipa.ipapython.install.cli.install_tool(Replica): ERROR  The 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


root@ipa02:~# echo $?
1

root@ipa02:~# cat /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with 
arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': 
None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, 
'no_pkinit': None, 'http_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, 
'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, 
'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, 
'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, 
'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 
'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, 
'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, 
'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, 
'dirsrv_cert_name': None, 'quiet': False, 'server': None, 
'setup_dns': None, 'host_name': None, 'log_file': None, 
'reverse_zones': None, 'allow_zone_overlap': None}

2017-02-22T22:49:45Z DEBUG IPA version 4.3.1
2017-02-22T22:49:45Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2017-02-22T22:49:45Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'

2017-02-22T22:49:45Z DEBUG httpd is configured
2017-02-22T22:49:45Z DEBUG kadmin is configured
2017-02-22T22:49:45Z DEBUG dirsrv is configured
2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured
2017-02-22T22:49:45Z DEBUG install is not configured
2017-02-22T22:49:45Z DEBUG krb5kdc is configured
2017-02-22T22:49:45Z DEBUG ntpd is configured
2017-02-22T22:49:45Z DEBUG named is not configured
2017-02-22T22:49:45Z DEBUG ipa_memcached is configured
2017-02-22T22:49:45Z DEBUG filestore has files
2017-02-22T22:49:45Z DEBUG   File 
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, 
in execute

return_value = self.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", 
line 318, in run

cfgr.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 308, in run

self.validate()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 317, in validate

for nothing in self._validator():
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 362, in __runner

step()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 359, in 

step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 81, in run_generator_with_yield_from

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 59, in run_generator_with_yield_from

value = gen.send(prev_value)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 564, in _configure

next(validator)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 449, in _handle_exception

self.__parent._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 446, in _handle_exception

super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-p

Re: [Freeipa-users] how to make email as mandatory field before user creation

[Standa Laznicka]

On 01/03/2017 06:45 PM, Petr Vobornik wrote:

On 01/02/2017 08:46 PM, nirajkumar.si...@accenture.com wrote:

Hi Prtr,

Can you please suggest how to do it with plugins and which plugin I need to use 
and how to integrate that plugin with freeipa.

Thanks
Niraj

Disclaimer: the example below is not really save because it doesn't
handle e.g. stageusers
... which you could perhaps ensure by replacing "user" with "baseuser" 
in the whole proposed "zuserplugin.py" file. It should not break more 
stuff than the proposed change I should hope :)

and it might not work with later releases of
FreeIPA because IPA doesn't provide any supported plugin API yet.

Example: https://pvoborni.fedorapeople.org/plugins/backend/zuserplugin.py

Old(FreeIPA 3.3) extending guide:
   http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf


-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: 02 January 2017 22:21
To: Singh, NirajKumar ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] how to make email as mandatory field before user 
creation

On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote:

Hi Team,

Is there any way to make email as mandatory field before creating any
user from WEBUI or Console?

Thanks & Regards,

Niraj Kumar Singh


Hello Niraj,

FreeIPA doesn't support such configuration out of the box.

It is theoretically possible to implement IPA server side plugin to mark the 
field as required. It may not be straightforward though.

--
Petr Vobornik



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.com





--
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] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively

[Standa Laznicka]

On 11/29/2016 09:35 PM, Robert Kudyba wrote:


On Nov 29, 2016, at 11:37 AM, Rob Crittenden > wrote:


Robert Kudyba wrote:

I知 trying to use the script posted on
https://urldefense.proofpoint.com/v2/url?u=https-3A__shellonearth.net_import-2Dlocal-2Daccounts-2Din-2Dfreeipa-2Drhelcentos_&d=DgIDAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=qUO21wyGfiMBRaZk6rjEMSMEMYZB0QpBVyQTCq3U6lw&s=9CmZV-vE0Nle4yup0VrHuHVnMuPNCBaOcJQkR4GzebM&e= 
.

I知 getting the below error. Have the options for ipa user-add changed
recently? Here痴 what the error looks like in context from the CLI:

Password for admin@ourdomain:
User login:
ipa: ERROR: Could not get User login interactively

Here is what痴 in the script:

ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL"
--displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr
userpassword='{crypt}$CRYPT'




Are you sure $USER has a value?

It looks like it is falling back on interactive prompting for required
fields.


Thanks that gave me a clue. The script was looking for a group ID of 8 
characters long I changed it to 4:
forline in"$(echo $p | grep "x:[0-9][0-9][0-9][0-9]*:")"# Only grep 
user accounts with IDs of 4 digits or more


But now the script just “hangs” and no response. I confirmed 
permissions of the shadow and passwd files and just using 20 login 
names from each file. Nothing shows up in the user search of the 
FreeIPA GUI.




Well, I may not be that fluent in bash as I used to be, but from what I 
see here, it's quite obvious. Line 39 - you have a `while read p` part 
there that waits for input from stdin. That's where you hang. How you 
managed to get to `ipa user-add` line before I am not really certain.


Did you perhaps mean to read from /tmp/passwd or /tmp/shadow on L39? :)

-- 
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] ipalib authentication

[Standa Laznicka]

On 11/24/2016 04:27 PM, Adam Bishop wrote:

I'm writing a bit of code using ipalib directly, I'm a little stuck on 
authentication though.

It works fine if grab a Kerberos ticket with kinit then run the code 
interactively, but I'd like to run this as a daemon which makes maintaining a 
ticket tricky.

What other options are there for authenticating to the API, avoiding calling 
external tools like curl or kinit?

Regards,

Adam Bishop

   gpg: E75B 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. GB 
197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, 
BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
by guarantee which is registered in England under company number 2881024, VAT 
number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, 
Bristol BS2 0JA. T 0203 697 5800.



Hello Adam,

Nice to see someone interested in FreeIPA development. For questions 
about developing FreeIPA, feel free to contact other developers at 
freeipa-de...@redhat.com (in CC). You can also create a pull request on 
GitHub (https://github.com/freeipa/freeipa) if you'd like to share your 
code with the community.


As for your question, would it be feasible to use keytabs? Sure, you 
still have to perform kinit but there's no user action required (except 
for maintaining the keytab, of course).


Standa

--
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 automount bug?

[Standa Laznicka]

Hello,

I am no automount expert so I will leave answering those questions to 
those but see my comment inline.


On 10/27/2016 06:16 AM, William Muriithi wrote:

Evening,

I am trying to import some autos map from a file to FreeIPA LDAP and
have noticed two problems that can be considered a bug in my humble
opinion.  This is on:

ipa-server-4.2.0-15.0.1.el7

1.  This either is a documentation bug that suggest one can specify a
parent map while thats actually not the case or ipa I am running has a
bug and can't handle parent map. Below is what I get when I try to
specify parent map:

[root@hydrogen ~]# ipa automountmap-add-indirect default
auto.projects-prs1013 –-mount=/projects/prs1013
--parentmap=auto.projects
Is this a direct copy-paste from the terminal? If so and your e-mail 
client did not do any reformatting then the first character in the 
"–-mount=/projects/prs1013" is not a dash, which results in it being 
recognized as a third argument, thus the warning about at most 2 arguments.


ipa: ERROR: command 'automountmap_add_indirect' takes at most 2 arguments

  I had got the idea that this is possible from the documentation below:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-maps.html

According to the document, I should be able to specify an automap
parent.  However, it don’t look like that’s actually supported.



2. How would one import an existing maps to ipa auto.home map.  Import
seem to be only capable of importing to auto.master, which make its
utility doubtful

[root@hydrogen ~]# ipa automountlocation-import  default
/tmp/2016-10-26/auto.home

Imported maps:
Imported keys:

Added adam to auto.master
..

I think we should have a flag that allow importation of key to other
other maps other than auto.master

Regards,
William



--
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