Re: [Freeipa-users] dns stops working after upgrade
On 11/05/2014 05:22 PM, Rob Verduijn wrote: I saw in the upstream foreman-prepare-realm script that the new permission names should include a prefix System: That Prefix is not there, what did change was that some permissions where no longer lower case only. ie in 3.3.5 the permission is 'write dns configuration' and in 4.1 it becomes 'Write DNS Configuration' Rob Right. There were some changes to IPA's default policy too, but I don't think it should affect the Foreman proxy very much. For example there are now permissions for reading data, but most are granted to all authenticated users by default. I've left some comments in the pull request. 2014-11-05 16:25 GMT+01:00 Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com: On 5.11.2014 16:20, Rob Verduijn wrote: Hello, Yes I noticed the name change it took me a while to realise it was a known ruby bug in katello that caused the real problem. I also checked after I updated the 'katello integrated' update from 3.3.5 to 4.1 and the permissions were neatly renamed to their new counterparts. However the internal dns no longer worked :( So the permissions broke after upgrade to 4.1, right? pviktori, can you give us some advice? Thanks! Petr^2 Spacek Rob 2014-11-05 16:17 GMT+01:00 Stephen Benjamin step...@redhat.com mailto:step...@redhat.com: On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: Also when I look at the permissions in ipa there are no longer any permissions that have the 'System: ' prefix. AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x because it was obsoleted by 'native' proxy delivered by Foreman upstream. Am I right, Rob (Crittenden)? :-) I believe he's referring to the native smart proxy here. It includes a script to setup permissions. I guess it hasn't been tested against a 4.x IPA master. The permissions have changed names in FreeIPA 4.0, which means the script won't work. I've tested this one against 4.1 on F21 and it works: https://raw.githubusercontent.__com/stbenjam/smart-proxy/8278/__sbin/foreman-prepare-realm https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm There's an open pull request against foreman's Smart Proxy to include that in the next release: https://github.com/theforeman/__smart-proxy/pull/231-- https://github.com/theforeman/smart-proxy/pull/231-- -- Petr³ -- 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-devel] Announcing FreeIPA 4.0.3
On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: FYI, for any Fedora testers out there, we have updated to 4.0.3 in Fedora 21 in part because it substantially reduces the size of the install media for the upcoming Alpha release. If you'd like to test and provide feedback on the packages, the link is here: https://admin.fedoraproject.org/updates/FEDORA-2014-10811 Actually, this update came too late for the Alpha. It will be considered for Beta. Use the updates-testing repo if you want to test FreeIPA in f21 Alpha. -- Petr³ -- 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] json api docs
On 09/12/2014 03:36 PM, Tamas Papp wrote: On 09/12/2014 02:47 PM, Martin Kosek wrote: On 09/11/2014 02:06 AM, Dmitri Pal wrote: On 09/10/2014 07:10 PM, Tamas Papp wrote: hi All, Is there an offficial API documentation available? Unfortunately not much. You can search archives and find some recommendations that helped people in the past. https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html We also have a ticket https://fedorahosted.org/freeipa/ticket/3129 We also have a ticket https://fedorahosted.org/freeipa/ticket/4233 targeted on FreeIPA 4.1 to see the actual JSON queries that ipa command sends. It would make it easier to see how we use the API. Actually what is the recommended way to use ipa as a simple ldap backend for a service without kerberos? In fact the service does not need kerberos and things like that, but I like the helper tools of ipa, like ipa command, web UI, easy replication etc. IPA is an integrated solution. Kerberos is built in and the other parts assume it's there. There's no recommended way without Kerberos. Can I make trouble by writing the directory directly though ldap (add/delete/modify users + groups). Yes, this will cause trouble. The IPA commands do additional processing, e.g. creating user private groups. -- Petr³ -- 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] Announcing FreeIPA 4.0.3
The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21 Beta. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Bug fixes in 4.0.3 == * Several issues concerning integration with 389 Directory Server 1.3.3 were fixed. * An upgrade crash was fixed. == Known Issues == * On Fedora 21 Alpha, FreeIPA server configuration should be done after upgrading packages from updates-testing. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.2 == === David Kupka (1) === * Fix typo causing ipa-upgradeconfig to fail. === Ludwig Krispenz (1) === * Update SSL ciphers configured in 389-ds-base === Nathaniel McCallum (1) === * Update qrcode support for newer python-qrcode === Petr Viktorin (4) === * Update referential integrity config for DS 1.3.3 * permission plugin: Auto-add operational atttributes to read permissions * Allow deleting obsolete permissions; remove operational attribute permissions * Become IPA 4.0.3 -- 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] Announcing FreeIPA 4.0.2
if /root/ipa.csr exists when installing server with external CA. * Exclude attributelevelrights from --raw result processing in baseldap. * Add test for baseldap.entry_to_dict. * Convert external CA chain to PKCS#7 before passing it to pkispawn. * Allow changing CA renewal master in ipa-csreplica-manage. * Add method for setting CA renewal master in LDAP to CAInstance. * Pick new CA renewal master when deleting a replica. * Normalize external CA cert before passing it to pkispawn * Add new NSSDatabase method get_cert for getting certs from NSS databases. * Make CA-less ipa-server-install option --root-ca-file optional. * Backup CS.cfg before modifying it === Martin Bašti (7) === * Fix DNS upgrade plugin should check if DNS container exists * FIX: named_enable_dnssec should verify if DNS is installed * Allow to add host if record exists * Tests: host tests with dns * Fix dnsrecord-mod raise error if last record attr is removed * FIX DNS wildcard records (RFC4592) * Tests: DNS wildcard records === Martin Košek (2) === * Do not crash client basedn discovery when SSF not met * ipa-adtrust-install does not re-add member in adtrust agents group === Nathaniel McCallum (1) === * Ensure ipaUserAuthTypeClass when needed on user creation === Petr Viktorin (8) === * Update API.txt * test_ipagetkeytab: Fix assertion in negative test * freeipa.spec.in: Add python-backports-ssl_match_hostname to BuildRequires * permission plugin: Make --target available in the CLI * permission plugin: Improve description of the target option * Add managed read permissions for compat tree * Fix: Add managed read permissions for compat tree and operational attrs * Become IPA 4.0.2 === Petr Voborník (10) === * webui: support wildcard attribute level rights * webui: fix nested items creation in dropdown list * webui: internet explorer fixes * webui: detach facet nodes * webui: replace action_buttons with action_widget * webui: remove remaining action-button-disabled occurrences * webui-ci: fix reset password check * webui: better error reporting * webui-ci: fix table widget add * webui: extract complex pkey on Add and Edit === Rob Crittenden (1) === * No longer generate a machine certificate on client installs === Stephen Gallagher (1) === * Change BuildRequires for Java === Tomáš Babej (3) === * ipalib: idrange: Make non-implemented range types fail the validation * ipatests: test_trust: Add test to cover lookup of trusdomains * ipa-client-install: Do not add already configured sources to nsswitch.conf entries -- Petr³ -- 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] Minimal permissions for joiner account?
On 08/15/2014 06:02 PM, James wrote: On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich mlasev...@lasevich.net wrote: Sorry, I did not intend to belittle your efforts - just misread the code Didn't take it that way, no worries :) (saw you pass in $admin and $password and made wrong assumption that $admin was admin username) as well as trying to avoid puppet as I find Salt much quicker and much simpler (and already established in my setup) I sat down tonight and threw together a quick salt reactor that does same thing as your module - creates the host account in IPA with a generated OTP password and joins the host to the domain using that generated OTP (and while at it, validates the host against AWS and populates the metadata into IPA) Ended up having to join the salt master to the domain, which I was avoiding doing for security reasons, but I can just disable IPA logins in PAM and call it a day. The nice bit is that it is using the host's keytab for authentication, so I do not need any extra credentials sitting around. Seems to be working just fine. :-). I ended up granting the salt-master host the Host Administrators privilege. It seems that Host Enrollment privilege is not sufficient to enroll hosts - go figure. Great! The only thing that bugs me is that I am calling IPA python code from my salt reactor python code via subprocess - there has got to be a better, more direct way - but I found documentation too confusing to follow at 1 am - will be a project for another day. There is the python ipa API, not sure how stable or official it is, but if you look in my code I use it occasionally. The RPC API is not official (i.e. documented), but since IPA needs to keep backwards compatibility with its own client, it's very stable. Just be sure to send the API version with each call. (The server will send a warning if you don't.) -- Petr³ -- 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] Enabling ntp if not done during ipa-server-install
On 08/15/2014 08:11 PM, Lucas Yamanishi wrote: On 08/15/2014 10:33 AM, Redmond, Stacy wrote: I installed my ipa server with –no-ntp but find that I want to enable it on my server, and all my replicas. Is it possible to do post install? Yes, you can do that. There’s no |ipa-ntp-install| command, because /NTP isn’t integrated with FreeIPA as much as it’s a good idea to run it along side FreeIPA/; Kerberos and other crypto operations depend on good time-sync. All you need to do to [...] Thanks for the instructions, Lucas. Adding it may be easy, but users don't necessarily know that, so it would make sense to provide an ipa-ntp-install command to take care of all the details. I filed a RFE for ipa-ntp-install: https://fedorahosted.org/freeipa/ticket/4497 -- Petr³ -- 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 + Ipsilon
On 08/05/2014 07:48 PM, Simo Sorce wrote:
On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote:
[...]
with HTTP 500 Internal Server Error (GET /idp HTTP/1.1 500 619)
The line is this one (in
/usr/lib/python2.6/site-packages/ipsilon/admin/login.py):
plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']}
Uhmm python 2.6, I think it does not support dict comprehension.
You can replace this line with:
dict([p.name, p for p in self._site[FACILITY]['enabled']])
dict((p.name, p) for p in self._site[FACILITY]['enabled'])
(You need the parens around (p.name, p))
--
Petr³
--
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] Objectclass ipaobject
On 07/29/2014 10:58 AM, Andreas Ladanyi wrote: Am 28.07.2014 15:30, schrieb Petr Viktorin: On 07/28/2014 03:08 PM, Andreas Ladanyi wrote: Hi, iam looking for the ldif file where i could find the objectclass definition of ipaobject. [...] So the objectclass ipaobject seems to have one auxiliary attribute only ? Where could i find the rest of the objectclass definition ? This is the complete definition; other attributes come from other objectclasses. The ipaUniqueID is required (MUST) for ipaObject. The objectclass itself is AUXILIARY. Here's the tutorial I learned LDAP concepts from, hope it helps: http://www.zytrax.com/books/ldap/ch3/ Hi Petr, thank you for your answer. This is the complete definition; other attributes come from other objectclasses. Ok, but from which other objectclasses ? That depends on the other objectclasses the entry has. ipaobject only provides ipaUniqueID, but (since it's auxiliary), the entry must have at least one other objectclass as well. For example, a user will have something like: dn: uid=admin,cn=users,cn=accounts,... objectclass: top objectclass: person objectclass: posixaccount objectclass: krbprincipalaux objectclass: krbticketpolicyaux objectclass: inetuser objectclass: ipaobject objectclass: ipasshuser objectclass: ipaSshGroupOfPubKeys a non-posix group will have: dn: cn=ipausers,cn=groups,cn=accounts,... objectclass: top objectclass: groupofnames objectclass: nestedgroup objectclass: ipausergroup objectclass: ipaobject etc. -- Petr³ -- 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] Difference between Masters and Replicas?
On 07/16/2014 02:34 PM, Choudhury, Suhail wrote: Hi, I'd like some clarification on what a master and replica is please. Once installed, all masters are identical (except some might have a CA and some not). The distinction is useful when installing a replica, where master and replica generally mean existing master and new master, respectively. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html That doc is ancient (Fedora 15), don't use it. However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.domain.com.gpg am I creating another master replica? Yes, you're creating a new master; since you gave --setup-ca the two masters will be equivalent. -- Petr³ -- 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 Install Failing with UnboundLocalError: local variable 'replman' referenced before assignment
On 07/15/2014 04:25 PM, Choudhury, Suhail wrote:
Hi Petr,
Yes definitely using IPA 3.0 packages as per the package details provided
earlier.
Ah, I see. This was reverted in a patch for EL6. Sorry for doubting you.
To get rid of the error, since you're not afraid to modify code, you can
follow the instruction inline:
The following code is present in the replica installer script:
# Try out the password
ldapuri = 'ldaps://%s' % ipautil.format_netloc(config.master_host_name)
Here, insert the line:
replman = None
try:
conn = ldap2(shared_instance=False, ldap_uri=ldapuri, base_dn='')
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=config.dirman_password,
tls_cacertfile=CACERT)
replman = ReplicationManager(config.realm_name,
config.master_host_name,
config.dirman_password)
found = False
try:
entry = conn.find_entries(u'fqdn=%s' % host, ['dn', 'fqdn'],
DN(api.env.container_host, api.env.basedn))
print The host %s already exists on the master server.\nYou should
remove it before proceeding: % host
print %% ipa host-del %s % host
found = True
except errors.NotFound:
pass
try:
(agreement_cn, agreement_dn) = replman.agreement_dn(host)
entry = conn.get_entry(agreement_dn, ['*'])
print A replication agreement for this host already exists. It needs
to be removed. Run this on the master that generated the info file:
print %% ipa-replica-manage del %s --force % host
found = True
except errors.NotFound:
pass
if found:
sys.exit(3)
except errors.ACIError:
sys.exit(\nThe password provided is incorrect for LDAP server %s %
config.master_host_name)
except errors.LDAPError:
sys.exit(\nUnable to connect to LDAP server %s %
config.master_host_name)
finally:
if conn and conn.isconnected():
conn.disconnect()
if replman and replman.conn:
replman.conn.unbind_s()
The background to this problem is that we have 6 x IPA servers, 2 each in 3 x
DCs.
In one DC we had a problem with storage which messed up the 2 IPAs, 1 of which
was the master from which replicas were originally taken.
After promoting a good IPA box in another DC(as per
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html)
I cannot now create new replicas to replace the two which were messed up.
But when trying to install them I am getting the error UnboundLocalError: local
variable 'replman' referenced before assignment.
Fixing the UnboundLocalError will reveal the real problem.
If you get LDAP server on ipabox1.domain.com is not responding. again,
please check if the server is really unreachable, using:
ldapsearch -x -s one -b cn=schema -h ipabox1.domain.com
Regards,
Suhail Choudhury.
DevOps | Recommendations Team | BSkyB
From: Petr Viktorin [pvikt...@redhat.com]
Sent: 15 July 2014 14:59
To: freeipa-users@redhat.com; Choudhury, Suhail
Subject: Re: [Freeipa-users] IPA Replica Install Failing with UnboundLocalError:
local variable 'replman' referenced before assignment
You say you are using the IPA 3.0 packages. Are you sure?
The UnboundLocalError should have been fixed in IPA 3.0.0 (as a side
effect of fixing https://fedorahosted.org/freeipa/ticket/2845 )
I checked the CentOS 3.5 srpm, and the fix is there. Yet it is missing
from the source you quote below.
On 07/15/2014 03:25 PM, Choudhury, Suhail wrote:
FYI,
These are IPA replicas being re-added.
I removing these replman lines in the installer script:
What do you mean by Removing the replman lines? Is this quote from
before or after you removed them?
# Try out the password
ldapuri = 'ldaps://%s' % ipautil.format_netloc(config.master_host_name)
try:
conn = ldap2(shared_instance=False, ldap_uri=ldapuri, base_dn='')
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=config.dirman_password,
tls_cacertfile=CACERT)
replman = ReplicationManager(config.realm_name,
config.master_host_name,
config.dirman_password)
found = False
try:
entry = conn.find_entries(u'fqdn=%s' % host, ['dn',
'fqdn'], DN(api.env.container_host, api.env.basedn))
print The host %s already
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 01:52 PM, Bret Wortman wrote:
I'm trying to stand up a new ipa server on a clean box, and I keep
getting this error so _something_ is amiss but I'm not sure what:
:
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
[1/22]: creating certificate server user
[2/22]: configuring certificate server instance
ipa: CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
Configuration of CA failed
#
In the /var/log/ipaserver-install.log, I see this:
:
:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed.
2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR PKI
subsystem 'CA' for instance 'pki-tomcat' already exists!
2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
2014-04-28T11:43:46Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 622, in run_script
return_value = main_function()
File /usr/sbin/ipa-server-install, line 1074, in main
dm_password, subject_base=options.subject)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
478, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.7/site-packages/ipaserver/isntall/service.py,
line 364, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
604, in __spawn_instance
raise RUntimeError('Configuration of CA failed')
:
:
So it looks like somehow this has gotten configured already. Possibly
Puppet copied over something it shouldn't have. What do I need to remove
to make this step work without removing so much that I render something
inoperable?
According to the error you're getting, there is a CA instance already
installed.
After uninstalling IPA, destroy it with:
pkidestroy -s CA -i pki-tomcat
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] JSON interface (Was: IPA DNS command line tools and ~)
On 03/07/2014 04:34 PM, Rich Megginson wrote:
[...]
The ipa command line tools use RPC, but they use XML. If you run ipa
-vv dnsrecord-add ... you can see the XML sent and received. There is a
bit of work converting from XML to JSON. e.g.
arraydatavaluestringtestdomain.com./string/valuevaluestringtestdomain.com/string/value/data/array
is
[testdomain.com., testdomain.com.]
[...]
Note that FreeIPA 4.0 (current git master) will use JSON-RPC by default,
so you'll no longer need to convert from XML.
It seems the -vv option is quickly becoming very useful for API users.
Currently the logging is very low-level; in current master I get:
$ ipa -vv ping
ipa: INFO: trying https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json
ipa: INFO: Forwarding 'ping' to json server
'https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json'
send: u'POST /ipa/session/json HTTP/1.1\r\nHost:
vm-244.idm.lab.eng.brq.redhat.com\r\nAccept-Encoding:
gzip\r\nAccept-Language: en-us\r\nReferer:
https://vm-244.idm.lab.eng.brq.redhat.com/ipa/xml\r\nCookie:
ipa_session=da66695e0c3a772a3fe649c3e1d11612;\r\nUser-Agent:
xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type:
application/json\r\nContent-Length: 64\r\n\r\n{params: [[],
{version: 2.77}], method: ping, id: 0}'
reply: 'HTTP/1.1 200 Success\r\n'
header: Date: Fri, 07 Mar 2014 15:48:31 GMT
header: Server: Apache/2.4.6 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6
NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
header: Set-Cookie: ipa_session=da66695e0c3a772a3fe649c3e1d11612;
Domain=vm-244.idm.lab.eng.brq.redhat.com; Path=/ipa; Expires=Fri, 07 Mar
2014 16:08:31 GMT; Secure; HttpOnly
header: Vary: Accept-Encoding
header: Content-Encoding: gzip
header: Content-Length: 176
header: Content-Type: application/json; charset=utf-8
body: '{\nerror: null, \nid: 0, \nprincipal:
ad...@idm.lab.eng.brq.redhat.com, \nresult: {\n
summary: IPA server version 3.3.90GITcb4dcd8. API version 2.77\n
}, \nversion: 3.3.90GITcb4dcd8\n}'
-
IPA server version 3.3.90GITcb4dcd8. API version 2.77
-
Would it be useful to also log pretty-printed JSON with `-vvv`, so
adventurous API explorers can just copy and paste?
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] JSON interface
On 03/07/2014 05:31 PM, Erinn Looney-Triggs wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2014 08:57 AM, Petr Viktorin wrote: On 03/07/2014 04:34 PM, Rich Megginson wrote: [...] The ipa command line tools use RPC, but they use XML. If you run ipa -vv dnsrecord-add ... you can see the XML sent and received. There is a bit of work converting from XML to JSON. e.g. arraydatavaluestringtestdomain.com./string/valuevaluestringtestdomain.com/string/value/data/array is [testdomain.com., testdomain.com.] [...] Note that FreeIPA 4.0 (current git master) will use JSON-RPC by default, so you'll no longer need to convert from XML. It seems the -vv option is quickly becoming very useful for API users. Currently the logging is very low-level; [...] Would it be useful to also log pretty-printed JSON with `-vvv`, so adventurous API explorers can just copy and paste? Umm, yes please! Filed as: https://fedorahosted.org/freeipa/ticket/4233 To the ticket I attached a crude patch I've been using; it can act as a starting point if someone wants to jump on this. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SELinux user categories
Moving to freeipa-devel since we're going rather deep. On 02/12/2014 10:02 AM, Martin Kosek wrote: On 02/11/2014 08:52 PM, Rob Crittenden wrote: Josh wrote: On Feb 11, 2014, at 2:44 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Josh wrote: I have a situation where I need to support more than 1024 categories on a system. I modified the selinuxusermap.py file to check for the number of categories I need but ipa still responds with the original error message. Do I need to restart any of the services? Here is the command that was run and the output after applying the patch below: ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] Have you updated your SELinux policy to support a larger MCS range? If not then this will get you past the IPA validator but it won't work with SELinux. See semanage(8). rob Yes. I’m trying to set the SELinux categories in freeipa because when you have lots of categories all semanage commands slow down (way down). For other people’s knowledge, this requires recompilation of the SELinux policy. Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. regards rob I am thinking you may be able to monkeypatch the validator in a custom plugin, like selinuxusermap-user.py which would: import ipalib.plugins.selinuxusermap( def custom_selinux_usermap_validator((ugettext, user): ... ipalib.plugins.selinuxusermap = custom_selinux_usermap_validator Then upgrade would not destroy the change. But of course, things may break as well if for example we change the params of this function. Martin No, I don't think something like that will work; the validator is baked into the Param on creation. You'd have to replace `selinuxusermap.takes_params` with a copy that has a new `ipaselinuxuser` Param. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute
On 02/06/2014 09:31 AM, barry...@gmail.com wrote:
Hi:
I can make it show on ldap browser or the ui but finding where to add it
in command base.
ipa user-mod ---employeenumber no such parameter.
You can use setattr where we don't provide specialized CLI arguments.
Also note that employeenumber won't show in the default output; you'll
want to use --all to retrieve all the attributes.
ipa user-mod somerandomuser --setattr=employeenumber=1234 --all
ipa user-show somerandomuser --all
To add this to the CLI, you would need to modify the user object in your
plugin. Something like:
from ipalib.plugins import user
from ipalib.parameters import Str
user.takes_params = user.takes_params + (
Str('employeenumber',
cli_name='first',
label=_('Employee number'),
),
)
Moreover can i change the attribute just by name and make use of it.
E.g. i found car license no really useful for staff so i want to change
the label to staff id card number
You should ideally create a new LDAP attribute for this, but the label
is defined in ipalib.plugins.user.
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute
On 02/06/2014 01:08 PM, Dmitri Pal wrote:
On 02/06/2014 05:59 AM, Petr Viktorin wrote:
On 02/06/2014 09:31 AM, barry...@gmail.com wrote:
Hi:
I can make it show on ldap browser or the ui but finding where to add it
in command base.
ipa user-mod ---employeenumber no such parameter.
You can use setattr where we don't provide specialized CLI arguments.
Also note that employeenumber won't show in the default output; you'll
want to use --all to retrieve all the attributes.
ipa user-mod somerandomuser --setattr=employeenumber=1234 --all
ipa user-show somerandomuser --all
To add this to the CLI, you would need to modify the user object in
your plugin. Something like:
from ipalib.plugins import user
from ipalib.parameters import Str
user.takes_params = user.takes_params + (
Str('employeenumber',
cli_name='first',
did you mean
cli_name='employeenumber'
?
Copy paste?
Right, sorry for the mistake.
label=_('Employee number'),
),
)
Moreover can i change the attribute just by name and make use of it.
E.g. i found car license no really useful for staff so i want to change
the label to staff id card number
You should ideally create a new LDAP attribute for this, but the label
is defined in ipalib.plugins.user.
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Export data
On 01/22/2014 06:26 PM, Dimitar Georgievski wrote: Would you use ldapmodify -f file-name-with-exported-data to import the data back to a new copy of FreeIPA? No, that generally won't work. There's more to IPA than the data in LDAP. Instead of copying data you should install the new server as a replica of the old one. Thanks Dimitar On Wed, Jan 22, 2014 at 8:52 AM, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 22.1.2014 14:40, Rob Crittenden wrote: Martin Kosek wrote: On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: Hi guys, I trying to get a dump of all users, hosts and DNS entries from IPA so we can run scripts/Puppet against them. Tried searching for it but cannot find anything, so was hoping someone can give some hints on how best to do this please. You can either export them via ldapsearch: $ kinit admin $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=__example,dc=com' ... or for write a Python script to do what you want. Very simple example: $ kinit admin $ python from ipalib import api api.bootstrap() api.finalize() api.Backend.xmlclient.connect(__) users = api.Command.user_find() for user in users['result']:... print %s:%s:%s % (user['uid'][0], user['uidnumber'][0], user['gidnumber'][0]) ... admin:191360:191360 tuser:191361:191361 Be aware that there are some search limits too, both in size and time. Some of this is configurable from the client side, some on the server. You can use standard zone transfer for DNS: See https://www.redhat.com/__archives/freeipa-users/2013-__September/msg00022.html https://www.redhat.com/archives/freeipa-users/2013-September/msg00022.html https://www.redhat.com/__archives/freeipa-users/2013-__September/msg00047.html https://www.redhat.com/archives/freeipa-users/2013-September/msg00047.html -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating
On 01/03/2014 02:23 AM, Will Sheldon wrote: This is cause for concern. Is there a hardening / best practices for production guide anywhere, did I miss a section of the documentation? What else do I need to secure? I understand that there is a tradeoff between security and compatibility, but maybe there should be a ipa-secure script somewhere? We are working on making the read permissions granular, so you can make your own tradeoffs if IPA defaults aren't appropriate for your use. The work is tracked in https://fedorahosted.org/freeipa/ticket/3566 and linked tickets 4032-4034. On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp jitsekl...@gmail.com mailto:jitsekl...@gmail.com wrote: It is possible to disable anonymous binds to the directory server. Take a look at https://docs.fedoraproject.__org/en-US/Fedora/18/html/__FreeIPA_Guide/disabling-anon-__binds.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html - Jitse On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: It exposes the details of all the users/admins in the environment. There should be a user that the IPA should use to fetch the details from the IPA Servers. Without Authentication , no one should be able to fetch any information from the IPA Server. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External CA
On 11/08/2013 09:01 AM, Martin Kosek wrote: Thanks for heads up. You mean by the difference between O=MW and O=MELTWATER.COM? Petr, is this possible? Can it be validated in the the installer if this is the root cause? It is possible. It's hard to tell without the logs; looks like the failure was inside Dogtag. There may be more issues; for instance I don't think we considered PEM files with extra data before the BEGIN CERTIFICATE. I filed a ticket to investigate: https://fedorahosted.org/freeipa/ticket/4019 On 11/08/2013 01:55 AM, William Leese wrote: I was able to solve this by recreating my test CA. I believe the problem was with non-matching Organisation between the CSR and CA - but I dont have the knowledge to know if this is really required. Anyhow, things work, despite not having removed the -BEGIN CERTIFICATE- lines this time around. Thanks for the help and sorry for wasting your time! -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External CA
On 11/07/2013 08:34 AM, William Leese wrote: [root@vagrant-centos-6 CA]# cat /root/server.pem Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, CN=vagrant.localdomain/__emailAddress=t...@t.com mailto:t...@t.com mailto:t...@t.com mailto:t...@t.com Validity Not Before: Nov 6 05:12:09 2013 GMT Not After : Nov 6 05:12:09 2014 GMT Subject: O=MELTWATER.COM http://MELTWATER.COM http://MELTWATER.COM, CN=Certificate Authority [snip] -BEGIN CERTIFICATE- MIIDfDCCAmSgAwIBAgIBAjANBgkqhk__iG9w0BAQUFADB5MQswCQYDVQQGEwJK__UDEL MAkGA1UECAwCVEsxDDAKBgNVBAcMA1__RLSzELMAkGA1UECgwCTVcxDDAKBgNV__BAsM A29wczEcMBoGA1UEAwwTdmFncmFudC__5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3__DQEJ [snip] Try removing everything before the -BEGIN CERTIFICATE- line from the PEM. Well that was unexpected: removing the BEGIN Certificate / End lines now makes the install proceed up until: The log file for this installation can be found in /var/log/ipaserver-install.log The PKCS#10 certificate is not signed by the external CA (unknown issuer E=x...@x.com mailto:x...@x.com,CN=vagrant-centos-6,OU=JP,O=JP,L=JP,ST=JP,C=JP). Can you please post more (all) of /var/lig/ipaserver-install.log? We need to know where exactly the issue is occuring and what the traceback is. Do I need to do anything to make my freshly created internal CA trusted for the installation? I've tried the usual magic in /etc/pki/tls/certs, but to no avail. No, --external_ca_file should have been enough. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External CA
On 11/06/2013 06:32 AM, William Leese wrote: Hi, Trying to install freeIPA and have it a sub-ca of an existing one. Sadly I'm not getting anywhere. The version I have installed: ipa-server-3.0.0-26.el6_4.4.x86_64 This is what I run: ipa-server-install -U -a testtest -p testtest --external_cert_file=/root/server.pem --external_ca_file=/root/cacert.pem -p testtest -P testtest -r MELTWATER.COM http://MELTWATER.COM Which runs this as part of the process: /usr/bin/pkisilent ConfigureCA -cs_hostname vagrant-centos-6.meltwater.com http://vagrant-centos-6.meltwater.com -cs_port 9445 -client_certdb_dir /tmp/tmp-bOrwSu -client_certdb_pwd testtest -preop_pin 4hdia3IvPvf27Qo7kBbO -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password testtest -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MELTWATER.COM http://MELTWATER.COM -ldap_host vagrant-centos-6.meltwater.com http://vagrant-centos-6.meltwater.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password testtest -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd testtest -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MELTWATER.COM http://MELTWATER.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MELTWATER.COM http://MELTWATER.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MELTWATER.COM http://MELTWATER.COM -ca_server_cert_subject_name CN=vagrant-centos-6.meltwater.com http://vagrant-centos-6.meltwater.com,O=MELTWATER.COM http://MELTWATER.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MELTWATER.COM http://MELTWATER.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MELTWATER.COM http://MELTWATER.COM -external true -ext_ca_cert_file /root/server.pem -ext_ca_cert_chain_file /root/cacert.pem All this results in this in the log: errorStringFailed to create pkcs12 file./errorString [snip] Error in BackupPanel(): updateStatus value is null ERROR: ConfigureCA: BackupPanel() failure ERROR: unable to create CA Can you attach the full error from the log? Interestingly adding the option -save_p12 false to the pkisilent command above results in: importCert string: importing with nickname: ipa-ca-agent Already logged into to DB ERROR:exception importing cert Security library failed to decode certificate package: (-8183) security library: improperly formatted DER-encoded message. ERROR: AdminCertImportPanel() during cert import ERROR: ConfigureCA: AdminCertImportPanel() failure ERROR: unable to create CA While the option change seemed innocent, I honestly don't know if its crucial to the install or not. Anyhow, things don't really progress anyway. I followed the documentation by signing the /root/ipa.csr with a test, internal CA but somehow I can't get the install to proceed. [root@vagrant-centos-6 CA]# cat /root/server.pem Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, CN=vagrant.localdomain/emailAddress=t...@t.com mailto:t...@t.com Validity Not Before: Nov 6 05:12:09 2013 GMT Not After : Nov 6 05:12:09 2014 GMT Subject: O=MELTWATER.COM http://MELTWATER.COM, CN=Certificate Authority [snip] -BEGIN CERTIFICATE- MIIDfDCCAmSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJKUDEL MAkGA1UECAwCVEsxDDAKBgNVBAcMA1RLSzELMAkGA1UECgwCTVcxDDAKBgNVBAsM A29wczEcMBoGA1UEAwwTdmFncmFudC5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3DQEJ [snip] Try removing everything before the -BEGIN CERTIFICATE- line from the PEM. [root@vagrant-centos-6 CA]# cat /root/cacert.pem -BEGIN CERTIFICATE- MIIDxTCCAq2gAwIBAgIJALIzKeNrwx2lMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNV BAYTAkpQMQswCQYDVQQIDAJUSzEMMAoGA1UEBwwDVEtLMQswCQYDVQQKDAJNVzEM MAoGA1UECwwDb3BzMRwwGgYD [snip] Any help would be welcome. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New login procedure for FreeIPA wiki - need advice!
On 11/06/2013 03:33 PM, Alexander Bokovoy wrote: On Wed, 06 Nov 2013, Pablo Carranza wrote: Have you guys/gals considered using Sphinx http://sphinx-doc.org/, instead (perhaps, in conjunction with ReadTheDocs.orghttps://readthedocs.org/ )? Yes, we considered it. Sphinx and ReadTheDocs are great for a library, but we're not really making a library. The tools we have now work well for us. That said, if we wanted to document ipapython or ipaldap and make them available for projects other than IPA, I think Sphinx would be the tool to use. I'm not sure how it helps -- we need a wiki working on FreeIPA org, it is part of our development routine to work jointly on feature development and we use wiki for that purpose -- see http://www.freeipa.org/page/V3_Designs We also have no need to use alternative hosting, current one is fine, so github is not really a solution. The developer docs, HOWTOs, release info, etc. are fine on the wiki. IPA's end-user documentation is in Docbook/Publican, hosted at https://git.fedorahosted.org/git/docs/freeipa-guide.git -- once we make it presentable we'll host the built docs on freeipa.org as well. (Of course it's a Git repo, anyone is free to make a mirror on Github. I'm sure you can find one :P) -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Query Tuning and a Recovery Question
On 09/26/2013 12:00 AM, Charlie Derwent wrote: On Mon, Sep 16, 2013 at 3:21 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: [...] http://freeipa.org/page/__TroubleshootingGuide#Replica___Re-Initialization http://freeipa.org/page/TroubleshootingGuide#Replica_Re-Initialization [...] You might want to edit the line on the link so nsSaslMapFilterTemplate: (krbPrincipalName=@IDM.LAB.BOS.REDHAT.COM http://IDM.LAB.BOS.REDHAT.COM) reads nsSaslMapFilterTemplate: (krbPrincipalName=@$REALM) but it's kind of obvious anyway. Thanks for noticing, I've fixed it. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] remove me from list
On 09/16/2013 12:43 PM, Ainsworth, Thomas wrote: please remove tainswo...@vsi-corp.com from the distro email list. Thanks, Tom Ainsworth Hello, This list is managed by Mailman. You can unsubscribe yourself at https://www.redhat.com/mailman/listinfo/freeipa-users (bottom of the page), or by sending an e-mail to freeipa-users-le...@redhat.com -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Fwd: Fwd: Scorched earth
On 08/30/2013 10:23 AM, Bret Wortman wrote: Morning update. I made the change Rob suggested to /etc/ipa/default.conf, which appeared to work, but didn't quite. It asked me to back out the whole server installation and start over: [ipamaster2]# ipa-ca-install --skip-conncheck replica-info-ipamaster2.foo.net.gpg Directory Manager (existing master) password: COnfiguring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exit status 1 Your system may be partly configured. Run/usr/sbin/ipa-server-install --uninstall to clean up. Can you look into /var/log/ipareplica-ca-install.log? It should have more information on what caused pkispawn to fail. Configuration of CA failed. [ipamaster2]# Which uninstallation cleanup I did. Now, when trying to re-install the replica file: [ipamaster2]# ipa-replica-install --setup-dns --no-forwarders --setup-ca /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg Directory manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipamaster.foo.net http://ipamaster.foo.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (686): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The followign list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@foo.net mailto:ad...@foo.net password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipamaster2.foo.net http://ipamaster2.foo.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (686): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK The host ipamaster2.foo.net http://ipamaster2.foo.net already exists on the master server. You should remove it before proceeding: % ipa host-del ipamaster2.foo.net http://ipamaster2.foo.net ipa : ERRORCould not resolve hostname ipamaster.foo.net http://ipamaster.foo.net using DNS Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.) Continue? [no]: *yes* [ipamaster2]# host ipamaster.foo.net http://ipamaster.foo.net ipamaster.foo.net http://ipamaster.foo.net has address 1.2.3.4 No matter what answer I give to the Continue? prompt, it just exits. nslookup returns the same value, and I have three different nameservers configured for this host (including ipamaster and two of the older replicas). The error that caused the installation to fail is that ipamaster2.foo.net already exists on the master server. The DNS warning and its Continue? prompt is unrelated, but the order of the output is very confusing. I've filed ticket 3889 for this. Anyway, to do this DNS resolution check you'd need to explicitly ask for the IPA server: $ dig @ipamaster.foo.net ipamaster2.foo.net And this message is the one that has prompted me to want to delete hosts before installing in the past, Simo. Any thoughts on how best to proceed now? I believe you do need to delete he host at this point, but I'd rather have Rob or Simo confirm. *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 2:59 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: Okay, I got the cacert.p12 (turns out it was taking my passphrase, but the messages looked like errors to my addled eyes). This system is on a different network, so getting the file transferred would take me about 24 hours. Is there something I can get that'll tell you what you need but is plaintext? Ok, that's fine. Try this. Set ra_plugin to dogtag in /etc/ipa/default.conf. This will let it get past the error and it should install a CA. I'm trying to think worst case scenario what it might do and I'm not coming up with anything. I think the worst that happens is that adding a CA fails later. rob I tried this and hope this subset of information is helpful: # openssl pkcs12 -in cacert.p12 -out cacert.pem.bdw -cacerts -nokeys # cat cacert.pem.bdw Bag Attributes:
[Freeipa-users] Announcing FreeIPA 3.3.1
The FreeIPA team is proud to announce FreeIPA v3.3.1! This is a bugfix release. It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds will be ready soon. == Highlights in 3.3.1 == === Bug fixes === * ipa-server-certinstall now works correctly both with a CA subsystem and in CA-less installations * The --subject option in ipa-server-install is now handled correctly * During installation, directory server tuning is performed correctly on sysV and systemd systems * During installation, the CA service is stopped during configuration file changes to prevent race conditions === Test improvements === * Integration tests for CA-less installation, Kerberos flags, and related Web UI parts were added to the test suite * Test suite now passes after ipa-adtrust-install == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. Please see http://www.freeipa.org/page/Howto/Dogtag9ToDogtag10Migration for details. === Other FreeIPA servers and clients === An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.0 == === Alexander Bokovoy (1): === * Remove systemd upgrader as it is not used anymore === Ana Krivokapic (4): === * Handle --subject option in ipa-server-install * Fix broken replica installation * Add integration tests for Kerberos Flags * Fix tests which fail after ipa-adtrust-install === Jakub Hrozek (1): === * EXTDOM: Do not overwrite domain_name for INP_SID === Jan Cholasta (12): === * Make PKCS#12 handling in ipa-server-certinstall closer to what other tools do. * Port ipa-server-certinstall to the admintool framework. * Remove unused NSSDatabase and CertDB method find_root_cert_from_pkcs12. * Ignore empty mod error when updating DS SSL config in ipa-server-certinstall. * Replace only the cert instead of the whole NSS DB in ipa-server-certinstall. * Untrack old and track new cert with certmonger in ipa-server-certinstall. * Add --pin option to ipa-server-certinstall. * Ask for PKCS#12 password interactively in ipa-server-certinstall. * Fix nsSaslMapping object class before configuring SASL mappings. * Add --dirman-password option to ipa-server-certinstall. * Fix ipa-server-certinstall usage string. * Fix service-disable in CA-less install. === Martin Kosek (3): === * Prevent *.pyo and *.pyc multilib problems * Remove rpmlint warnings in spec file * Fix selected minor issues in the spec file and license === Nathaniel McCallum (1): === * Bypass ipa-replica-conncheck ssh tests when ssh is not installed === Petr Viktorin (4): === * Allow freeipa-tests to work with older paramiko versions * Add missing license header to ipa-test-config * Add CA-less install tests * Add man pages for testing tools === Petr Vobornik (7): === * Removal of deprecated selenium tests * Add base-id, range-size and range-type options to trust-add dialog * Hide 'New Certificate' action on CA-less install * Web UI integration tests: CA-less * Web UI Integration tests: Kerberos Flags * Web UI integration tests: ID range types * Update idrange search facet after trust creation === Rob Crittenden (1): === * Re-order NULL check in ipa_lockout. === Simo Sorce (3): === * pwd-plugin: Fix ignored return error * kdb-mspac: Fix out of bounds memset * kdb-princ: Fix memory leak === Sumit Bose (1): === * CLDAP: make sure an empty reply is returned on any error === Tomas Babej (6
Re: [Freeipa-users] ipa-server-install problem
On 06/14/2013 03:37 PM, Josh wrote: I'm trying to install freeipa on RHEL6.4 running version ipa-server-3.0.0-26.el6_4.2.x86_64 but it keeps failing at the Configuration of CA failed. I believe the problem is that the python used to generate the perl command doesn't wrap any of the arguments in quotes. The command doesn't go through the shell so quoting is not necessary. I can see how the the log line is confusing, though; I filed https://fedorahosted.org/freeipa/ticket/3724. [1/20]: creating certificate server user ipa : DEBUGca user pkiuser exists ipa : DEBUG duration: 0 seconds ipa : DEBUG [2/20]: configuring certificate server instance [2/20]: configuring certificate server instance ipa : DEBUGargs=/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname jokajak.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-nRzpxE -client_certdb_pwd -preop_pin 5czI1yO2iWaHLp2WlffW -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host jokajak.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM -ca_server_cert_subject_name CN=jokajak.example.com,O=EXAMPLE.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external false -clone false ipa : DEBUGstdout=libpath=/usr/lib64 ### ### ipa : DEBUGstderr=sh: -c: line 0: syntax error near unexpected token `)' sh: -c: line 0: `java -cp /usr/share/java/pki/pki-silent.jar:/usr/share/java/pki/pki-certsrv.jar:/usr/share/java/pki/pki-cmscore.jar:/usr/share/java/pki/pki-nsutil.jar:/usr/share/java/pki/pki-cmsutil.jar:/usr/share/java/pki/pki-tools.jar:/usr/share/java/ldapjdk.jar:/usr/share/java/xerces-j2.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/xml-commons-resolver.jar:/usr/lib/java/dirsec/jss4.jar:/usr/lib/java/jss4.jar:/usr/lib/java/dirsec/osutil.jar:/usr/lib/java/osutil.jar: ConfigureCA -cs_hostname jokajak.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-nRzpxE -client_certdb_pwd -preop_pin 5czI1yO2iWaHLp2WlffW -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host jokajak.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM -ca_server_cert_subject_name CN=jokajak.example.com,O=EXAMPLE.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external false -clone false' ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname jokajak.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-nRzpxE -client_certdb_pwd -preop_pin 5czI1yO2iWaHLp2WlffW -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host jokajak.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM -ca_server_cert_subject_name CN=jokajak.example.com,O=EXAMPLE.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external false -clone false' returned non-zero exit status 255 ipa : INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File
Re: [Freeipa-users] user-custom script
On 05/27/2013 12:50 PM, Sigbjorn Lie wrote:
Hi,
A while back I got some help writing a python script who extends the user
classes in ipalib to run
a custom command when a user is added/modified/deleted. This has been working
perfectly in our
production environment for a few years now, until I upgraded to IPA 3.0 last
week. The custom
script is no longer executed.
Did the libraries change since 2.2?
Hello,
Yes, IPA did change, though not in the callback registration API. See
comment below.
The script sits in
/usr/lib/python2.6/site-packages/ipalib/plugins/user-custom.py and looks like:
#
# Extension to provide user-customizable script when a user id
added/modified/deleted
#
from ipapython import ipautil
# Extend add
from ipalib.plugins.user import user_add
def script_post_add_callback(inst, ldap, dn, attrs_list, *keys, **options):
inst.log.info('User added')
if 'ipa_user_script' in inst.api.env:
try:
ipautil.run([inst.api.env.ipa_user_script,add, dn])
except:
pass
First of all, you can add better logging so you can diagnose errors more
easily, e.g.:
try:
ipautil.run([inst.api.env.ipa_user_script,add, dn])
except Exception, e:
inst.log.error(ipa_user_script: Exception: %s, e)
With this change, I can see the following line in the server log:
ipa: ERROR: ipa_user_script: Exception: sequence item 2: expected string
or Unicode, DN found
The error is due to DN refactoring
(https://fedorahosted.org/freeipa/ticket/1670). All DNs throughout IPA
are now represented by DN objects. To use them as strings you need to
convert them explicitly:
ipautil.run([inst.api.env.ipa_user_script, add, str(dn)])
The same change is needed in the other three cases.
The modified code should still work under IPA 2.2.
Let me know if you're having more trouble.
return dn
user_add.register_post_callback(script_post_add_callback)
# Extend delete
from ipalib.plugins.user import user_del
def script_post_del_callback(inst, ldap, dn, attrs_list, *keys, **options):
inst.log.info('User deleted')
if 'ipa_user_script' in inst.api.env:
try:
ipautil.run([inst.api.env.ipa_user_script,del, dn])
except:
pass
return dn
user_del.register_post_callback(script_post_del_callback)
# Extend modify
from ipalib.plugins.user import user_mod
def script_post_mod_callback(inst, ldap, dn, attrs_list, *keys, **options):
inst.log.info('User modified')
if 'ipa_user_script' in inst.api.env:
try:
ipautil.run([inst.api.env.ipa_user_script,mod, dn])
except:
pass
return dn
user_mod.register_post_callback(script_post_mod_callback)
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deleting a down ipa master?
On 05/02/2013 03:49 PM, Lager, Nathan T. wrote: I have an IPA server that i'm rebuilding. It was part of a 3 server replication. That is, three ipa replicas. Caroline0 through 2. I have the server rebuilt, the problem is, it wasn't cleanly removed from the ipa replication in the first place, so the other two replicas still think it exists. I thought it should be a simple matter of deleting the down replica on the other two, but thats not working out. Yes, I understand that it should have been cleanly uninstalled, and that would have avoided this. Live and learn. Here's some detail. Caroline1 is the server which is to be rebuilt. [root@caroline2 PROD ~]# ipa-replica-manage list caroline0.lafayette.edu: master caroline2.lafayette.edu: master caroline1.lafayette.edu: master [root@caroline2 PROD ~]# ipa-replica-manage del caroline1.lafayette.edu 'caroline2.lafayette.edu' has no replication agreement for 'caroline1.lafayette.edu' [root@caroline2 PROD ~]# ipa host-del caroline1.lafayette.edu ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled I have tried the same commands from Caroline0, which is the first ipa server i built, thinking that maybe it was in some way authoritative in some matters because it was the first. Same deal there. I've tried simply re-adding my rebuilt caroline1, hoping it would replace the old, no luck there. The host caroline1.lafayette.edu already exists on the master server. You should remove it before proceeding: % ipa host-del caroline1.lafayette.edu I think the key here is to convince the other two ipa servers, that caroline1 is no longer a master, but I haven't found a way to do that yet. Use the --force: ipa-replica-manage del --force caroline1.lafayette.edu The command tries severs replication agreements before deleting info about the replica. With --force it will ignore the fact that there's no agreement and continue on. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deleting a down ipa master?
On 05/02/2013 04:17 PM, Nathan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm sorry, I should have mentioned that I've tried that already. Here's the ouput. [root@caroline2 PROD ~]# ipa-replica-manage del --force caroline1.lafayette.edu 'caroline2.lafayette.edu' has no replication agreement for 'caroline1.lafayette.edu' Thanks! Hmm. The error should be displayed, but the command should continue on if there is info about the replica... Try running the command with -v to get more info. You can use the --cleanup option as a last resort. Also, could you check ipa-replica-manage list again, to make sure it's still there? Sometimes it's not clear if the command worked. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deleting a down ipa master?
On 05/02/2013 05:21 PM, Nathan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 List still shows caroline1. [root@caroline2 PROD ~]# ipa-replica-manage list caroline0.lafayette.edu: master caroline2.lafayette.edu: master caroline1.lafayette.edu: master - -v does not seem to change the output at all. I even tried moving the - -v around in the command line, to see if placement mattered. [root@caroline2 PROD ~]# ipa-replica-manage -v del --force caroline1.lafayette.edu 'caroline2.lafayette.edu' has no replication agreement for 'caroline1.lafayette.edu' [root@caroline2 PROD ~]# ipa-replica-manage del -v --force caroline1.lafayette.edu 'caroline2.lafayette.edu' has no replication agreement for 'caroline1.lafayette.edu' [root@caroline2 PROD ~]# ipa-replica-manage del --force -v caroline1.lafayette.edu 'caroline2.lafayette.edu' has no replication agreement for 'caroline1.lafayette.edu' [root@caroline2 PROD ~]# ipa-replica-manage list caroline0.lafayette.edu: master caroline2.lafayette.edu: master caroline1.lafayette.edu: master Is --cleanup destructive? Is there some reason that it should not try it? Looking at the code, it only cleans up the Kerberos info and host entry, not DNS records or RUV. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] exporting ldap certificate
Hello, On 04/26/2013 07:22 AM, Peter Brown wrote: Hi everyone. I am attempting to get Google Apps to sync with FreeIPA and I am having problems getting the sync utility to talk to freeipa. It complains about the ssl cert. I have it setup so it only accepts ssl or tls encrypted connections and I don't want to turn that off. I have imported the ca cert using the jre's keytool but it still refuses to connect. I am getting the impression I need to import the ssl cert for the ldap server into it as well. The CA cert (/etc/ipa/ca.crt) should be enough, it signs all the other certs. Make sure you import it with the right trust level (SSL certificate signing). Unfortunately I don't know about jre's keytool so I can't be more specific. I have no idea which certificate that is and I have no idea how to export it. Do not do this. You should only explicitly trust the CA cert. For example, if you trust the certs explicitly you'd have to re-import them one by one when they are renewed. Can someone please tell me how to do this? If you really want to: There are two certs, one for httpd (Web UI, XMLRPC JSON APIs), and one for the LDAP server. To export the httpd server certificate (to PEM): $ certutil -L -d /etc/httpd/alias -n Server-Cert -a To export the directory server certificate (to PEM): $ certutil -L -d /etc/dirsrv/slapd-$INSTANCE_NAME/ -n Server-Cert -a But again, you don't need this for what you're trying to do. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Heads-up: Removing self-sign CA
On 03/28/2013 09:10 AM, Christian Horn wrote: Hi, On Tue, Mar 26, 2013 at 05:02:34PM +0100, Petr Viktorin wrote: We will soon be introducing a way to install IPA with custom certificates without a CA at all. When that is merged, it will no longer be possible to install a self-sign server. I see that the change in functionality is in line with generic unix principles, linux distros have already tools to create and manage own, self signed CA's. To clarify: this is about removing the --selfsign option to ipa-server-install, which installs a limited CA (for example, it doesn't support CA replication or cert-find). The default Dogtag CA also uses a self-signed certificate, but it's not affected by this change. The naming confusion is a small part of the reason why it's better to remove --selfsign. Yet from what I understand, this change will make all test setups more complicated. One has then by oneself to deploy an own CA (i.e. with the openssl tools) and have it sign the IPA cert. Use the default Dogtag CA for test setups. It will still use a self-signed CA certificate by default. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Heads-up: Removing self-sign CA
Hello list, FreeIPA's self-sign CA is a holdout from days where the our integration with a real CA wasn't that good. Also its name is confusing: the Dogtag CA also uses a self-signed certificate by default. We will soon be introducing a way to install IPA with custom certificates without a CA at all. When that is merged, it will no longer be possible to install a self-sign server. After that, the plan is to convert existing self-sign masters to CA-less on upgrade, and remove the self-sign code. On a CA-less master, IPA's cert commands will no longer be available and cert rotation will need to be done manually. Documentation on how to do this (using the existing self-signed CA cert) will be provided. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] What does the u mean in IPA messages?
On 03/01/2013 10:30 PM, John Dennis wrote: On 03/01/2013 04:01 PM, John Dennis wrote: On 03/01/2013 03:17 PM, KodaK wrote: On Thu, Feb 28, 2013 at 5:01 PM, John Dennis jden...@redhat.com wrote: On 02/28/2013 05:34 PM, KodaK wrote: BTW, why are you parsing diagnostic output? I haven't actually started yet, I was just getting my bearings. I was going to wrap the commands in some scripts so I can do things like allow an auditor to view the results of an HBAC test without being able to modify them. Among other things. Is there a way to turn off the diagnostic messages? They appear to be on by default. INFO messages are output when the verbose flag is enabled DEBUG messages are output when the debug flag is enabled Those flags can either be set in a config file (/etc/ipa/default.conf or ~/.ipa/default.con) or via a command line argument. If you haven't passed the verbose flag to the command then it must be set in one of the config files. Petr Viktorin pvikt...@redhat.com recently cleaned up how messages are managed in the command line tools (I don't think this has made it out into a public release yet). So there may be changes coming you'll want to be aware of, perhaps Petr might fill us in on what's different. I think we had some client tools that forced verbose to be enabled when it should have respected a command line option and/or config option. I think that's some of what Petr fixed. Here is the design document for the work Petr did, HTH http://freeipa.org/page/V3/Logging_and_output I don't think it's too relevant here. Those changes are mainly for install/management tools, and they're only in ipa-ldap-updater and ipa-replica-prepare commands so far. As for future changes: no, we don't have any guarantees on diagnostic messages, and I don't think catering to parsers should prevent us from improving them. Anyway, do you really need to parse debug messages to get HBAC test results? I think I don't understand your use case enough to suggest something better. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Transferring mastership to a new server
On 02/25/2013 03:04 PM, Bret Wortman wrote: So I managed to replicate my old IPA master onto a new server, and now I'd like that server to be the center of the universe. The master from which all (new) replicas are created. At present, there are no other replicas, just this one server now that the original has been decommissioned. I did discover that I can't create replicas from it because it knows it was cloned from another. What do I need to do to it so that it can take over as the new master? Install the CA on it (ipa-ca-install). If you have DNS set up, you'll want to run ipa-dns-install as well. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] JSON-RPC documentation?
Hello Brian,
On 01/15/2013 03:55 AM, Brian Smith wrote:
That helps a lot. Thanks! I would use ipalib, but I'm developing a
Rails application, so the JSON interface is the quickest (and since XML
may be deprecated)
While XML may be deprecated, it'll stick around for a long time. But
JSON is a good choice.
best way forward (unless you know a way to use it in
Ruby :). I'm guessing in JSON, the structure would look something like
this:
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:mySecretPasswordBlahBlah
...
}
]
}
Maybe I'll try to compile some documentation. I know that this page
helped a lot, to cook up a quick ruby client with Curb:
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
I've just CC-d you on a patch to the devel list that switches the IPA
client to JSON-RPC. To use it:
- Check out the git master and apply the patch
- Copy /etc/ipa/default.conf to ~/.ipa/default.conf
- Now a command like `./ipa -vv user-find` will print out the JSON it
sends receives.
It dumps the whole request/response so the output is not ideal for your
use, but I'm sure you can handle it.
It works from the source tree, no build/installation required.
You probably found out that the CLI options and API options/LDAP
attributes sometimes have different names. The `ipa show-mappings`
command can give you a mapping table.
One more thing: please add the API version to your requests to prevent
surprises down the road. The official client doesn't currently always do
that; this is a bug. You can get the current version with `ipa ping`:
$ ipa ping
--
IPA server version 3.1.0. API version 2.47
--
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:mySecretPasswordBlahBlah
...
version: 2.47,
}
]
}
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?
On 01/11/2013 09:57 PM, John Dennis wrote:
On 01/11/2013 03:52 PM, Dmitri Pal wrote:
On 01/11/2013 03:27 PM, John Dennis wrote:
On 01/11/2013 03:10 PM, Dmitri Pal wrote:
On 01/10/2013 11:00 AM, John Dennis wrote:
On 01/10/2013 08:15 AM, Petr Spacek wrote:
Hello,
is there any user of CSV support built-in to IPA administration tools
(ipa
command)? Do you consider it sane or even useful? Please reply.
I've always disliked our use of CSV values on both the command line
and internally. They're just weird, nothing else in Unix works like
this and as you point out below there are easier better alternatives.
Plus with the use of CSV's there is a lot of awkward quoting in a
variety of places.
On the command line I always thought multiple values should be
specified multiple times and internally they should be encapsulated in
lists rather than parsing a CSV string (if it's logically a list then
why isn't it a list?)
However at this juncture I'm not sure we can make such a change, we
have a published API that we would be violating. But perhaps we're not
so far down the road we can't make such a change and we're better off
doing it now while there is even a chance. It's not clear to me how
much the command line is being used and specifically with CSV values.
Do I think CSV's are sane and useful? No. Can we change that? That's a
whole other story.
I wanted to add single TXT record with double quotation marks ()
inside the
TXT data.
I spent some time figuring out how it is supposed to work ... and
with help of
Petr^3 I managed to write the command.
The resulting command (for BASH) is absolutely crazy:
ipa dnsrecord-add example.test. newrec --txt-rec='created on
13:01:23'
Do we really need support for this piece of insanity? Shells can do
the same
thing with much less pain :-)
IPA with CSV support can add multiple attributes at once, e.g.
ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9
will add TXT records with value 1, 2, 3 etc.
BASH can do the same thing (without the escaping hell):
ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9}
and
ipa dnsrecord-add example.test. newrec --txt-rec={1..9}
BASH would expand to
ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2
--txt-rec=3
--txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8
--txt-rec=9
Do we already have CSV support?
Where is it used?
It is not clear to me if BASH example above requires the CSV support or
it does expansion on its own. Please explain.
We already have CSV support. It's a mechanism that allows multiple
values to be passed for one command line argument. The alternate
approach is rather than having one command line arg that takes
multiple values is to allow multiple command line args, each one
taking a single value. This is the UNIX methodology. I believe the
original thinking was who would want to type out multiple command line
args, it's too verbose. However the shell expansion illustrated above
shows how with simple shell syntax one can have succicent args and
allow the shell to expand them into the preferred verbose form.
So both are already supported and we want to stop using CSV and
deprecate it over time?
This makes sense if there are good examples of how to use bash expansion.
I suggest we create a page and describe preferred method of dealing with
the lists and document it.
Also do the same with the manual, i.e. review it to make sure we do not
show CSV syntax in the docs, same with the man pages.
On the project page we will say that CSV will not be added to the new
and existing commands and will be deprecated over time (probably by IPA
version 4).
Do I get it right?
I'm not sure both are currently supported. I'm not sure we permit
multiple args with the same name and aggregate them, I thought that was
part of the proposal.
We do support multiple arguments.
The trouble with CSV is that to put commas (or in some cases double
quotes) in the data, they need to be escaped in a way that's not
intuitive. The proposal is to change this, so that instead of
--txt-rec='created on 13:01:23'
you can use just
--txt-rec='created on 13:01:23'
and instead of
--txt-rec='Record one, record two'
you need to say
--txt-rec={'Record one','record two'}
The assumption is that this makes more sense to a sysadmin, who is much
more likely to know bash scripting than our flavor of CSV escaping.
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa admin tool error ipa: ERROR: Client is not configured. Run ipa-client-install.
On 01/07/2013 11:00 AM, Natxo Asenjo wrote: hi, on a workstation *not* joined to the IPA domain but with the the ipa admin tools installed I get this error when trying to modify dns settings and I have a kerberos ticket of an admin user: $ kinit user.ad...@unix.domain.tld Password for user.ad...@unix.domain.tld $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: user.ad...@unix.domain.tld Valid starting ExpiresService principal 01/07/13 10:47:09 01/08/13 10:47:06 krbtgt/unix.domain@unix.domain.tld renew until 01/14/13 10:47:06 $ ipa dnsrecord-mod unix.domain.tld ipaclient01 --ttl=300 ipa: ERROR: Client is not configured. Run ipa-client-install. Is this 'by design'? This limitation on the cli tool does not apply to the web interface, by the way, that is, I can login the web interface without being joined to the domain and modify all kind of stuff there ;-). To be more specific: this is not a problem, I can run this command on a joined host, but I was just curious. Create a config file in /etc/ipa/default.conf or ~/.ipa/default.conf (or somewhere else and point ipa to it using the -c option). Copy the `xmlrpc_uri` line from a config on a master or joined machine there. ipa should work then. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA3 beta - CA will not install
On 07/24/2012 03:57 PM, Michael Mercier wrote: Hello, I am attempting to install the IPA 3.x beta on Fedora 17 and running into some difficulty. I performed the following steps attempting the install (following setup instructions for FreeIPA 2.2): 1. Download Fedora 17 2. Install Fedora 17 with VMWare 3. add hostname to /etc/hosts - 172.16.112.10 ipaserver.beta.local ipaserver 4. yum update 5. open the following ports on the firewall tcp 80,443,389,636,88,464,53,7839 udp 88,464,53,123 iptables -L ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldap ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldaps ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:kerberos ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:kpasswd ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:7389 ACCEPT udp -- anywhere anywhere state NEW udp dpt:kerberos ACCEPT udp -- anywhere anywhere state NEW udp dpt:kpasswd ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain ACCEPT udp -- anywhere anywhere state NEW udp dpt:ntp 6. Disable NetworkManger and enable network 7. reboot 8. add freeipa repository baseurl=http://freeipa.com/downloads/devel/rpms/F$releasever/$basearch 9. yum install freeipa-server bind bind-dyndb-ldap 10. ipa-server-install Attached is the log file. Thanks, Mike This was reported a while ago, see https://www.redhat.com/archives/freeipa-users/2012-July/msg00167.html for the workaround. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] UID 999, not possible?
On 07/03/2012 05:55 AM, Nathan Kinder wrote: On 06/29/2012 07:10 AM, Petr Viktorin wrote: On 06/29/2012 03:55 PM, Alexander Bokovoy wrote: On Fri, 29 Jun 2012, Petr Viktorin wrote: On 06/29/2012 03:04 PM, Alexander Bokovoy wrote: On Thu, 28 Jun 2012, sysad...@noboost.org wrote: Hi All, Is there a weird restriction to UID 999 in ipa, as IPA keeps changing the UID when I add a user with that number? (I've already checked the UID isn't in use) We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by an allocated one with the help of the 389-ds plugin http://directory.fedoraproject.org/wiki/DNA_Plugin http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values The documentation mentions that the magic value can be a word (magic), or it doesn't have to exist at all (it's added for objectClass:posixAccount entries). Is there a reason IPA is using 999 here? uidNumber and gidNumber field use integer value syntax: OID value: 1.3.6.1.4.1.1466.115.121.1.27 OID description: Values in this syntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the number 1321 is represented by the character string 1321. So, you can't have string there that does not evaluate to integer. That's true, but according to the documentation you linked, uidNumber/gidNumber syntax doesn't matter. The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA plugin sees and modifies the value before it's validated as an integer. I wouldn't trust this, as DNA was initially designed/implemented before we added syntax validation to 389. DNA was also written to be able to work with non integer attributes, where values have some sort of prefix followed by an integer (such as user1, user2, etc.). For this reason, dnaMagicRegen was left as Directory String syntax. I personally feel that it is safer to have the magic value be syntactically valid for the attribute that DNA is configured to generate. Best go with a negative number then. The DS docs should be updated if you don't trust what they say, though. On 06/29/2012 04:23 PM, Alexander Bokovoy wrote: Looks like you are right: http://comments.gmane.org/gmane.linux.redhat.fedora.directory.user/10641 We would have issue on our side when using non-integer value as Int() parameter does not support non-integer values. However, we could select some negative value as default one and use the same value for DNA configuration. The value can be optional, the server can fill in the default if it's not received from the client. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] UID 999, not possible?
On 06/29/2012 03:55 PM, Alexander Bokovoy wrote: On Fri, 29 Jun 2012, Petr Viktorin wrote: On 06/29/2012 03:04 PM, Alexander Bokovoy wrote: On Thu, 28 Jun 2012, sysad...@noboost.org wrote: Hi All, Is there a weird restriction to UID 999 in ipa, as IPA keeps changing the UID when I add a user with that number? (I've already checked the UID isn't in use) We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by an allocated one with the help of the 389-ds plugin http://directory.fedoraproject.org/wiki/DNA_Plugin http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values The documentation mentions that the magic value can be a word (magic), or it doesn't have to exist at all (it's added for objectClass:posixAccount entries). Is there a reason IPA is using 999 here? uidNumber and gidNumber field use integer value syntax: OID value: 1.3.6.1.4.1.1466.115.121.1.27 OID description: Values in this syntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the number 1321 is represented by the character string 1321. So, you can't have string there that does not evaluate to integer. That's true, but according to the documentation you linked, uidNumber/gidNumber syntax doesn't matter. The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA plugin sees and modifies the value before it's validated as an integer. If there is, the command should fail instead of silently assigning a different number than asked for. I'll file a bug for this. DNA_MAGIC in user.py is defined to 999 and it is default value to uidNumber and gidNumber options. We have no way to differentiate between default and entered by user but the same value. Yes, the server would need to verify if the client has been fixed. This means either waiting for the next major API version, or looking at the version/capabilities the client sends us. (See Martin's message from 2012-06-20 in thread [Freeipa-devel] [PATCH] 0062 Don't crash when server returns extra output). [root@sysvm-ipa ~]# ipa user-add administrator --uid=999 --gidnumber=132 --first=administrator --last=administrator -- Added user administrator -- User login: administrator First name: administrator Last name: administrator Full name: administrator administrator Display name: administrator administrator Initials: aa Home directory: /home/administrator GECOS field: administrator administrator Login shell: /bin/bash Kerberos principal: administra...@example.com UID: 72162 GID: 132 Keytab: False Password: False cya Craig ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] is not an IPA v2 Server.
On 06/18/2012 03:44 PM, george he wrote: Hello all, here is the error message from /var/log/ipaclient-install.log on the client machine: Connecting to myserver|myserver ip|:80... failed: No route to host. Retrieving CA from myserver failed. Command '/usr/bin/wget -O /tmp/tmpjibrhe/ca.crt -T 15 -t 2 http://myserver/ipa/config/ca.crt' returned non-zero exit status 4 Seems like a routing issue. Can you ping myserver from the client machine? but httpd seems running on myserver and port 80 is open. # systemctl status httpd.service httpd.service - The Apache HTTP Server (prefork MPM) Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Sun, 17 Jun 2012 11:17:07 -0400; 22h ago Process: 16225 ExecStop=/usr/sbin/httpd $OPTIONS -k stop (code=exited, status=0/SUCCESS) Process: 16230 ExecStart=/usr/sbin/httpd $OPTIONS -k start (code=exited, status=0/SUCCESS) Main PID: 16233 (httpd) CGroup: name=systemd:/system/httpd.service ├ 16231 /usr/sbin/nss_pcache 1212421 off /etc/httpd/alias ├ 16233 /usr/sbin/httpd -k start ├ 16236 /usr/sbin/httpd -k start ├ 16237 /usr/sbin/httpd -k start ├ 16238 /usr/sbin/httpd -k start ├ 16239 /usr/sbin/httpd -k start ├ 16240 /usr/sbin/httpd -k start ├ 16241 /usr/sbin/httpd -k start ├ 16242 /usr/sbin/httpd -k start ├ 16243 /usr/sbin/httpd -k start ├ 16244 /usr/sbin/httpd -k start └ 16245 /usr/sbin/httpd -k start I have been working on this for days to set this thing up. Any help will be very appreciated. George *From:* george he george_...@yahoo.com *To:* freeipa-users@redhat.com freeipa-users@redhat.com *Sent:* Saturday, June 16, 2012 4:02 PM *Subject:* is not an IPA v2 Server. Hello all, I'm trying to install freeipa for a small lab with 10 computers, all running fedora 17. I seemed to have installed ipa server (without DNS) successfully, # ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING but when I try to run ipa-client-install on a client machine, I get this error message: server.my.edu http://server.my.edu/ is not an IPA v2 Server. Installation failed. Rolling back changes. IPA client is not configured on this system. what am I missing? ps, I'm following the instructions here: https://docs.fedoraproject.org/en-US/Fedora/16/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html Thanks, George ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] is not an IPA v2 Server.
Hi, If you run the wget manually (downloading to an existing directory instead of /tmp/tmpjibrhe), do you get the same error? Can you connect to the web UI from the client? On 06/18/2012 04:12 PM, george he wrote: Hello Petr, I can ping or ssh to myserver with no problem. btw, here are the ports I opened: iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 389 -j ACCEPT iptables -A INPUT -p tcp --dport 636 -j ACCEPT iptables -A INPUT -p tcp --dport 88 -j ACCEPT iptables -A INPUT -p udp --dport 88 -j ACCEPT iptables -A INPUT -p tcp --dport 464 -j ACCEPT iptables -A INPUT -p udp --dport 464 -j ACCEPT iptables -A INPUT -p tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 123 -j ACCEPT Thanks, George *From:* Petr Viktorin pvikt...@redhat.com *To:* freeipa-users@redhat.com freeipa-users@redhat.com *Cc:* george he george_...@yahoo.com *Sent:* Monday, June 18, 2012 10:06 AM *Subject:* Re: [Freeipa-users] is not an IPA v2 Server. On 06/18/2012 03:44 PM, george he wrote: Hello all, here is the error message from /var/log/ipaclient-install.log on the client machine: Connecting to myserver|myserver ip|:80... failed: No route to host. Retrieving CA from myserver failed. Command '/usr/bin/wget -O /tmp/tmpjibrhe/ca.crt -T 15 -t 2 http://myserver/ipa/config/ca.crt' http://myserver/ipa/config/ca.crt%27 returned non-zero exit status 4 Seems like a routing issue. Can you ping myserver from the client machine? but httpd seems running on myserver and port 80 is open. # systemctl status httpd.service httpd.service - The Apache HTTP Server (prefork MPM) Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Sun, 17 Jun 2012 11:17:07 -0400; 22h ago Process: 16225 ExecStop=/usr/sbin/httpd $OPTIONS -k stop (code=exited, status=0/SUCCESS) Process: 16230 ExecStart=/usr/sbin/httpd $OPTIONS -k start (code=exited, status=0/SUCCESS) Main PID: 16233 (httpd) CGroup: name=systemd:/system/httpd.service ├ 16231 /usr/sbin/nss_pcache 1212421 off /etc/httpd/alias ├ 16233 /usr/sbin/httpd -k start ├ 16236 /usr/sbin/httpd -k start ├ 16237 /usr/sbin/httpd -k start ├ 16238 /usr/sbin/httpd -k start ├ 16239 /usr/sbin/httpd -k start ├ 16240 /usr/sbin/httpd -k start ├ 16241 /usr/sbin/httpd -k start ├ 16242 /usr/sbin/httpd -k start ├ 16243 /usr/sbin/httpd -k start ├ 16244 /usr/sbin/httpd -k start └ 16245 /usr/sbin/httpd -k start I have been working on this for days to set this thing up. Any help will be very appreciated. George *From:* george he george_...@yahoo.com mailto:george_...@yahoo.com *To:* freeipa-users@redhat.com mailto:freeipa-users@redhat.com freeipa-users@redhat.com mailto:freeipa-users@redhat.com *Sent:* Saturday, June 16, 2012 4:02 PM *Subject:* is not an IPA v2 Server. Hello all, I'm trying to install freeipa for a small lab with 10 computers, all running fedora 17. I seemed to have installed ipa server (without DNS) successfully, # ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING but when I try to run ipa-client-install on a client machine, I get this error message: server.my.edu http://server.my.edu/ http://server.my.edu/ is not an IPA v2 Server. Installation failed. Rolling back changes. IPA client is not configured on this system. what am I missing? ps, I'm following the instructions here: https://docs.fedoraproject.org/en-US/Fedora/16/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html Thanks, George ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Petr³ -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Provision user accounts groups from external IM
On 06/05/2012 12:51 PM, Alexander Bokovoy wrote: On Tue, 05 Jun 2012, Willem Bos wrote: Hi Alexander, Thanks for your quick response. Yes, the server on which the external IM environment is hosted does not have the ipa utils available. As a matter of fact, the server might even be hosted off-site. We're just beginning to explore IM solutions for our environment and the most likely architecture is a 'meta-IM' service that provisions platform specific IM's like AD, Oracle's Internet Directory and IPA. It will probably be a requirement that the meta-IM is to provision IPA directly (instead of Meta-IM - AD - IPA). The JASON interface looks promising, I will certainly try the example provided. Would user_add be the suitable command to use? It's the obvious candidate, but I just want to make sure... Yes, user_add is the command. Also note that the RPC calls use LDAP attribute names, which are often different from the CLI parameters. You can use the show-mappings command to figure out the names to use: $ ipa show-mappings user-add Parameter : LDAP attribute = : == first : givenname last: sn cn : cn displayname : displayname initials: initials homedir : homedirectory gecos : gecos shell : loginshell principal : krbprincipalname email : mail random : random uid : uidnumber gidnumber : gidnumber street : street city: l state : st postalcode : postalcode phone : telephonenumber mobile : mobile pager : pager fax : facsimiletelephonenumber orgunit : ou title : title manager : manager carlicense : carlicense sshpubkey : ipasshpubkey noprivate : noprivate Be careful as there currently are no warnings if you misspell an argument (we're working on that). -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
