Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 04/29/2015 12:15 PM, Martin Basti wrote: On 29/04/15 08:52, Jan Cholasta wrote: Dne 29.4.2015 v 08:45 Martin Kosek napsal(a): On 04/29/2015 07:34 AM, Jan Cholasta wrote: ... The command line tool class should be named ServerUpgrade rather than IPAServerUpgrade for consistency with others. The deprecated --debug option should not be used in new commands. Why is --debug option deprecated? I thought we wanted to deprecate --verbose option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated which for some reasons marks --debug as deprecated. It does not matter now, given the command is removed/changed. AdminTool provides --debug as a deprecated alias for --verbose when a subclass requests it. It seems the decision to deprecate --debug was already made back when AdminTool was introduced, so let's trust that decision. Yes that is reason. No, it's not. I will update design as well Nope. This decision was never made this way, AFAIR. --debug is what all the main tools (ipa-server-install, ipa-replica-install, ipa-client-install) use and we never agreed that we want to change it. In fact, I think I remember some discussion from Devconf.cz time, when we mentioned that the ipa-ldap-updater has it the deprecated status wrong way, that we want --debug. CCing Simo since he may have been in the conversation. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 29/04/15 12:39, Martin Kosek wrote: On 04/29/2015 12:15 PM, Martin Basti wrote: On 29/04/15 08:52, Jan Cholasta wrote: Dne 29.4.2015 v 08:45 Martin Kosek napsal(a): On 04/29/2015 07:34 AM, Jan Cholasta wrote: ... The command line tool class should be named ServerUpgrade rather than IPAServerUpgrade for consistency with others. The deprecated --debug option should not be used in new commands. Why is --debug option deprecated? I thought we wanted to deprecate --verbose option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated which for some reasons marks --debug as deprecated. It does not matter now, given the command is removed/changed. AdminTool provides --debug as a deprecated alias for --verbose when a subclass requests it. It seems the decision to deprecate --debug was already made back when AdminTool was introduced, so let's trust that decision. Yes that is reason. No, it's not. I will update design as well Nope. This decision was never made this way, AFAIR. --debug is what all the main tools (ipa-server-install, ipa-replica-install, ipa-client-install) use and we never agreed that we want to change it. In fact, I think I remember some discussion from Devconf.cz time, when we mentioned that the ipa-ldap-updater has it the deprecated status wrong way, that we want --debug. CCing Simo since he may have been in the conversation. http://freeipa.org/page/V3/Logging_and_output In commands that currently have it, the `-d, --debug` option will become a deprecated alias for --verbose. -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 04/29/2015 12:50 PM, Martin Basti wrote: On 29/04/15 12:39, Martin Kosek wrote: On 04/29/2015 12:15 PM, Martin Basti wrote: On 29/04/15 08:52, Jan Cholasta wrote: Dne 29.4.2015 v 08:45 Martin Kosek napsal(a): On 04/29/2015 07:34 AM, Jan Cholasta wrote: ... The command line tool class should be named ServerUpgrade rather than IPAServerUpgrade for consistency with others. The deprecated --debug option should not be used in new commands. Why is --debug option deprecated? I thought we wanted to deprecate --verbose option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated which for some reasons marks --debug as deprecated. It does not matter now, given the command is removed/changed. AdminTool provides --debug as a deprecated alias for --verbose when a subclass requests it. It seems the decision to deprecate --debug was already made back when AdminTool was introduced, so let's trust that decision. Yes that is reason. No, it's not. I will update design as well Nope. This decision was never made this way, AFAIR. --debug is what all the main tools (ipa-server-install, ipa-replica-install, ipa-client-install) use and we never agreed that we want to change it. In fact, I think I remember some discussion from Devconf.cz time, when we mentioned that the ipa-ldap-updater has it the deprecated status wrong way, that we want --debug. CCing Simo since he may have been in the conversation. http://freeipa.org/page/V3/Logging_and_output In commands that currently have it, the `-d, --debug` option will become a deprecated alias for --verbose. I see, I must somehow missed that aspect of the miniframework. Well, question is - is it really a good decision and thing we should do? I.e. slowly moving towards --verbose option, deprecating --debug, given we use --debug in most commands and people are using it? This could cause lot of unnecessary churn in stable distributions that would wish to rebase to FreeIPA, like CentOS or RHEL - and for what reason? I will be against removing --debug option from the main commands unless there is a very good reason and justification to do so. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 04/29/2015 12:59 PM, Martin Kosek wrote: On 04/29/2015 12:50 PM, Martin Basti wrote: On 29/04/15 12:39, Martin Kosek wrote: On 04/29/2015 12:15 PM, Martin Basti wrote: On 29/04/15 08:52, Jan Cholasta wrote: Dne 29.4.2015 v 08:45 Martin Kosek napsal(a): On 04/29/2015 07:34 AM, Jan Cholasta wrote: ... The command line tool class should be named ServerUpgrade rather than IPAServerUpgrade for consistency with others. The deprecated --debug option should not be used in new commands. Why is --debug option deprecated? I thought we wanted to deprecate --verbose option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated which for some reasons marks --debug as deprecated. It does not matter now, given the command is removed/changed. AdminTool provides --debug as a deprecated alias for --verbose when a subclass requests it. It seems the decision to deprecate --debug was already made back when AdminTool was introduced, so let's trust that decision. Yes that is reason. No, it's not. I will update design as well Nope. This decision was never made this way, AFAIR. --debug is what all the main tools (ipa-server-install, ipa-replica-install, ipa-client-install) use and we never agreed that we want to change it. In fact, I think I remember some discussion from Devconf.cz time, when we mentioned that the ipa-ldap-updater has it the deprecated status wrong way, that we want --debug. CCing Simo since he may have been in the conversation. http://freeipa.org/page/V3/Logging_and_output In commands that currently have it, the `-d, --debug` option will become a deprecated alias for --verbose. I see, I must somehow missed that aspect of the miniframework. Well, question is - is it really a good decision and thing we should do? I.e. slowly moving towards --verbose option, deprecating --debug, given we use --debug in most commands and people are using it? This could cause lot of unnecessary churn in stable distributions that would wish to rebase to FreeIPA, like CentOS or RHEL - and for what reason? I will be against removing --debug option from the main commands unless there is a very good reason and justification to do so. Martin I talked to Martin in person. If --debug option is not removed and is kept in the old commands and you really want to go with the --verbose option crusade, I can live with it. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] bind-dyndb-ldap meta-database design page
Hello, design page for bind-dyndb-ldap ticket #151 Implement internal meta-database is now ready for review: https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/MetaDB This feature does not have any user interface. It is just an auxiliary database for internal purposes. The main goal is to have something extensible which can cover all use-cases (listed in the design page). Better ideas what to use instead of RBTDB or linked list (mentioned in Implementation section) are more than welcome. Have a nice day! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] manage replication topology in the shared tree
Hi, thanks again, so there is some work to do, but see some answers inline
On 04/27/2015 10:18 AM, thierry bordaz wrote:
On 04/21/2015 10:49 AM, Ludwig Krispenz wrote:
On 04/20/2015 06:00 PM, thierry bordaz wrote:
On 04/13/2015 10:56 AM, Ludwig Krispenz wrote:
Hi,
in the attachment you find the latest state of the topology
plugin, it implements what is defined in the design page:
http://www.freeipa.org/page/V4/Manage_replication_topology (which
is also waiting for a reviewer)
It contains the plugin itself and a core of ipa commands to manage
a topology. to be really applicable, some work outside is required,
eg the management of the domain level and a decision where the
binddn group should be maintained.
Thanks,
Ludwig
Hello Ludwig,
Quite long review to do. So far I only looked at the startup phase
and I have only few questions and comments.
Thanks for your time, and I'm looking forward to your review of the
other parts, you raise some valid points.
I'll try to answer some of them inline, but will integrate some into
a next version of the patch
In ipa_topo_start, do you need to get argc/argv as you are not using
plugin-argxx attributes ?
no. It was a leftover from a standard plugin
topo_plugin_conf configuration parameters are not freed when the
plugin is closed. Is it closed only at shutdown ?
Also I would initiatlize it to {NULL}.
So far it is not planned to be dynamic, but I will addres the memory
management
In case the config does not contain any
nsslapd-topo-plugin-shared-replica-root, I wonder if
ipa_topo_apply_shared_config may crash as shared_replica_root will
be NULL.
or at least in
ipa_topo_apply_shared_replica_config/ipa_topo_util_get_replica_conf.
Also if nsslapd-topo-plugin-shared-replica-root contains an invalid
root suffix (typo), topoRepl remains NULL and
ipa_topo_util_get_replica_conf/ipa_topo_cfg_replica_add can crash.
for the two comments above, I was assuming that plugin conf and
shared tree would be setup by ipa tools and server setup, so assuming
only valid data, but you are right, checking for bad data doesn't hurt.
In ipa_topo_util_segment_from_entry, if the config entry has no
direction/left/right it will crash. Shouldn't it return an error if
the config is invalid.
adding a segment should be done with the ipa command 'ipa
topologysegment-add ...' and this always provides a direction (param
or default). If you try to add a segment directly, direction is a
required attribute of teh segment objectclass, so it should be rejected-
The update of domainLevel may start the plugin. If two mods update
the domainLevel they could be done in parallele.
yes :-(
In ipa_topo_util_update_agmt_list, if there is a marked agmnt but no
segment it deletes the agreement.
Is it possible there is a segment but no agmnt ? For example, if the
server were stopped or crashed after the segment was created but
before the local config was updated.
then it should be created from the segment
Hosts are taken from shared config tree (cn=masters,cfg), is it
possible to have a replica agreement to a host that is not under
'cn=masters,cfg'
yes, it will be ignored by the plugin
thanks
thierry
Hi Ludwig,
I continued the review of the design/topology plugin code. This is
really an interesting plugin but unfortunately I have not yet reviewed
all the parts.
I went through the design and digging the related parts in the code.
So far I need to review the rest starting at
http://www.freeipa.org/page/V4/Manage_replication_topology#connectivity_management.
I think I did ~50% design but may be more than 50% of the code.
Here are additional points:
in ipa_topo_set_domain_level, you may record the new Domain level
value as FATAL (it is already recorded in case of oneline import)
this just records the actual domain level, I don't think we need to log
it every time, only if it is changed should be sufficient (to verify)
ipa_topo_be_state_change is called for any backend going online.
Domain level and start should be done only for a backend mapping a
shared-replica-root.
yes, the comment is already there, but the actual check isn't, so it
would be recreated at online init of any backend, think it is not too
bad, but will change it
Also the plugin can be started many times (each online init),
ipa_topo_util_start is not protected by a lock
Some fields will leak (in ipa_topo_init_shared_config)
Also I wonder if you reinit several times the same replica-root,
its previous config will leak. (replica-repl_segments)
you shouldn't :-), but needs to be made safer
In ipa_topo_apply_shared_replica_config,
I do not see where replica_config is kept (leak ?)
it is created and set to the shared_conf data, but if it aready exists,
it will leak (that's probably the case above), it should be freed when
the plugin is stopped
ipa_topo_util_start/ipa_topo_apply_shared_config is called
Re: [Freeipa-devel] [PATCHES 0031-0032] set up a dedicated CCache file for Apache during install/upgrade
On 04/28/2015 05:42 PM, Martin Babinsky wrote: The attached patches address https://fedorahosted.org/freeipa/ticket/4973 and implement the solution proposed in Comment 2. Please review the hell out of them. Why did you split the work in 2 patches? It looks like you first did the first approach of modifying httpd.service and then changed your mind and did the ipa-httpd.service approach (which is what we agreed to). Also, shouldn't ipa-httpd.service be contained in the package itself, like ipa-dnskeysyncd and httpd.service masked during installation? Also, I do not see any daemon-reload, so I am not sure if systemd would pick up the right configuration in the first install. Next, I was thinking what should be the ideal KRB5CCNAME for the HTTPD service. You chose /tmp/ipa-httpd.ccache, is it the best approach CCACHE type/path we should use? This is mostly question to Simo, his mod_auth_gssapi will consume the ccache. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV
Dne 27.4.2015 v 16:46 Martin Basti napsal(a): On 27/04/15 13:05, Martin Basti wrote: On 23/04/15 13:06, Martin Basti wrote: On 16/04/15 17:14, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4984 I had to remove CSV (which is evil) to be able fix this ticket. Patches attached. Updated patches attached. -- Martin Basti Rebased patches attached. -- Martin Basti rebased patches attached -- Martin Basti ACK on patch 231. BTW I have found a 7 year old bug caused by CSV while reviewing it: https://fedorahosted.org/freeipa/ticket/5007. There is also similar git-only bug in install/updates/10-uniqueness.update: default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' default:uniqueness-subtrees: 'cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX' but your patch fixes it. I will review patch 232 later. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Suggestion for the A part of IPA
On 28/04/2015 19:08 PM, Young, Adam wrote: I think I am in alignment with what you are saying. I like rsyslogd as the basic ship the log off the server tool. Let's use what the platform support first natively and formost; We want something native, not Ruby, not even Python if we can avoid it, for the normal case. Bumping up to logstash for more complex host-side rules might be fine. Remember, the Hosts side of integration with FreeIPA is sssd. Logstash can be the server side of the audit collection as well, and then it puts fewer demands on the server. We need to ensure that the audit data can be sent over a GSSAPI protected pathway. Absolutely - this is something I need to get round to. Concentrated on getting the data back and in a good state for a start. Figured I'd get round to securing stuff at a later point. On the IPA side, I would think we would register the audit server as a host, and have specific service entires for the protocols supported. Would you see IPA owning the audit server, or just integrating in with an existing one? I've built mine completely separately and then brought them closer together by running Logstash on the IPA server. Not sure if there should be an exclusive ownership going on. IPA could create an initial setup, but there's huge room for creating more complex systems that IPA might want to leave well alone. I don't think the IPA server itself should be the ELK server for obvious reasons. I would love to see the ELK server supported along the lines of how we do a replica setup. ELK is trivial to set up as a simple cluster. It gets more complicated to do it properly, but what I've got going at the moment fits along the trivial lines, but provides an extremely robust database. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Suggestion for the A part of IPA
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: 29 April 2015 07:42 To: Innes, Duncan; freeipa-devel@redhat.com Subject: Re: [Freeipa-devel] Suggestion for the A part of IPA On 04/28/2015 05:58 PM, Innes, Duncan wrote: Folks, The A part of IPA has always been of great interest to me. Our current IPA infrastructure works well at the I P parts, giving us great failover abilities and connectivity through hardware firewalls without punching too many holes. Good to hear :-) We recently also started investigating the Audit capabilities for (notice I write for and not in) IPA. You can check my initial nudge to the freeipa-users list, which was unfortunately with no reply: https://www.redhat.com/archives/freeipa-users/2015-March/msg00940.html For the beginning, I would be interested for your use cases, if you are only looking for a centralized log store, or you are also looking for more analytics in the logs (like what API commands were run, user logins, etc.) or utilization of the server core services (LDAP/Kerberos/DNS/...) I'm actually interested in both pieces. It started off as generic centralised logging, but when I moved from plain rsyslog data to sending JSON formatted data I started getting richer and richer data. I got the IPA servers sending their dirsrv access and error logs back by using rsyslog's imfile module. http://www.freeipa.org/page/Howto/Centralised_Logging_with_Logstash/Elas ticSearch/Kibana This isn't too good, however, as imfile polls on an interval with my version of rsyslog7 and IPA logs are written only with HH:MM:SS level accuracy. (I'm sure there was a ticket to increase timestamp resolution, but I can't find it right now) But now I've got a load of the IPA logs back centrally, I'm beyond my own abilities in parsing much good stuff out of it. I haven't even parsed it out into any key:value pairs yet - which would be a big boost to ELK Searching on it. Whilst the A part may not be solely about centralised logging, it's the thing I've been looking into recently. To do this I've built a setup around the ELK stack using a pair of Logstash servers and an ElasticSearch cluster of 5 servers (overkill on the ES side perhaps, but this is proof of concept still). To expand on this, I've been looking at running the Logstash serviceon each of our IPA servers as that gives us a failover pair in each part of our network. The Logstash servers then connect to the ES cluster as non-data nodes. Each client has an rsyslog7 (still using RHEL6 at the moment) config that writes sends the logs in JSON format with some extra bespoke fields added (such as Project, Environment, and Use to help us search better). The sending is done in rsyslog's rather clunky failover method to the local pair of Logstash servers (with a third failover being to /dev/null). Ah, so you are running Logstash service on each IPA service? Isn't that too heavyweight? In our tests, we mostly simply wanted just configure rsyslog and get the logs out of the server, to the centralized ELK/REK/EFK servers which did the heavy lifting. After all, the IPA servers may be of different environments (Fedora, RHEL, CentOS, ...) and with different versions of the log processing software. The Logstash servers really don't produce much load on our systems. I expected them to, but it didn't materialise. The load may be a lighter due to me using rsyslog templates to send the logs pre-formatted as JSON? On the REK server (yes, we did not use logstash at the POC), we are able to process the logs (make them structured), store and display them. This allows us do searches like list of admins which added users in the last month. This if course required adding parsing rules to rsyslog to get the structure out of the API logs. Are you using logstash for the parsing or did you not start the parsing part yet? No parsing of the dirsrv logs yet. I've been concentrating on pushing the Whole centralised logging issue from PoC to Production so far. The IPA logs were a side-issue for us, but it's definitely something that would help if could get them properly structured. It struck me that this kind of setup might not be too far removed from some of the A part of IPA. The centralized log processing itself is a too big task for IPA itself, it is specialized on other things. But some integration should be added in time, I agree. It may be minimal, from top of my head for example: * Support of (rsyslog) configuration in ipa-client-install or ipa-server-install * Providing the secure, GSSAPI-based log transfer to the IPA clients and ELK/REK/EFK server * Providing parsing templates for rsyslog or base queries for Kibana That sounds the right way to start for sure. I've also been tracking journalctl's ability to send logs to an ELK setup. This is already looking to be a much simpler setup once a few
Re: [Freeipa-devel] [PATCHES 0031-0032] set up a dedicated CCache file for Apache during install/upgrade
On 04/29/2015 09:09 AM, Martin Kosek wrote: On 04/28/2015 05:42 PM, Martin Babinsky wrote: The attached patches address https://fedorahosted.org/freeipa/ticket/4973 and implement the solution proposed in Comment 2. Please review the hell out of them. Why did you split the work in 2 patches? It looks like you first did the first approach of modifying httpd.service and then changed your mind and did the ipa-httpd.service approach (which is what we agreed to). I was thinking about it as a two distinct operations (modify existing httpd.service to use KRB5CCNAME and rename httpd.service to ipa-httpd.service). But I can merge them if needed. Also, shouldn't ipa-httpd.service be contained in the package itself, like ipa-dnskeysyncd and httpd.service masked during installation? Also, I do not see any daemon-reload, so I am not sure if systemd would pick up the right configuration in the first install. Martin^2 told me that generating service file from template is evil, so I will put the full service file into init/systemd directory so that it is already present in /etc/systemd/system after rpm install. Next, I was thinking what should be the ideal KRB5CCNAME for the HTTPD service. You chose /tmp/ipa-httpd.ccache, is it the best approach CCACHE type/path we should use? This is mostly question to Simo, his mod_auth_gssapi will consume the ccache. I will ask Simo if there is some preferred way to name CCache files. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 04/29/2015 07:34 AM, Jan Cholasta wrote:
Dne 27.4.2015 v 18:23 David Kupka napsal(a):
On 04/27/2015 04:45 PM, Martin Basti wrote:
On 27/04/15 13:38, Martin Basti wrote:
On 23/04/15 12:55, Martin Basti wrote:
On 21/04/15 10:31, Martin Basti wrote:
On 21/04/15 08:12, Jan Cholasta wrote:
Hi,
Dne 15.4.2015 v 16:26 Martin Basti napsal(a):
https://fedorahosted.org/freeipa/ticket/4904
Patches attached.
Also ipa-upgradeconfig part is called as a subprocess. This will be
removed after installer modifications.
This patch may cause temporal upgrade issues (corner cases), until
installer part will be finished.
If somebody will be hit by them, please use --skip-version-check for
ipactl and ipa-server-upgrade.
Regarding that option vs. --force: I think the common assumption is
that --force ignores *all* non-fatal errors, but you break that
assumption in ipactl. IMO --force should both ignore errors in
service startup *and* skip version check, and a new option should
be added to just ignore errors in service startup (e.g.
--ignore-service-failures).
Originally I used --force option to skip detection, but there was
objections against it on list.
However, to have option --force, which set true for both
--ignore-service-failures and --skip-version-check options, might be
better.
ipa-server-upgrade should probably also have --force, even if it
does the same thing as --skip-version-check, again because --force
is common.
This is a weird API:
+if data_upgrade.badsyntax:
+raise admintool.ScriptError(
+'Bad syntax detected in upgrade file(s).', 1)
+elif data_upgrade.upgradefailed:
+raise admintool.ScriptError('IPA upgrade failed.', 1)
+elif data_upgrade.modified:
+self.log.info('Data update complete')
+else:
+self.log.info('Data update complete, no data were
modified')
Why does not IPAUpgrade raise errors instead?
For historical reasons, I can investigate what would break this
change, I will send it in separate patch.
+class IPAVersionError(Exception):
+pass
+
+class PlatformMismatchError(IPAVersionError):
+pass
+
+class DataUpgradeRequiredError(IPAVersionError):
+pass
+
+class DataInNewerVersionError(IPAVersionError):
+pass
I don't like the IPA in IPAVersionError, it does not tell you
much about what kind of version is that. Also data version errors
should only tell you what is wrong, not how you fix it. IMO better
names for these would be e.g. UpgradeVersionError,
UpgradePlatformError, UpgradeDataOlderVersionError,
UpgradeDataNewerVersionError. Similar for store_ipa_version and
check_ipa_version.
Ok.
Why is it not an error if there is no version in check_ipa_version?
IMO it should, even if you then ignore the exception most of the
time.
I can raise error in that case and ignore the exception.
Honza
Martin^2
Updated patches attached.
Updated patches attached
--
Martin Basti
Updated patch attached
Looks good to me and works as expected. Honza, are you OK with the patches?
Some nitpicks:
The command line tool class should be named ServerUpgrade rather than
IPAServerUpgrade for consistency with others.
The deprecated --debug option should not be used in new commands.
Why is --debug option deprecated? I thought we wanted to deprecate --verbose
option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated
which for some reasons marks --debug as deprecated. It does not matter now,
given the command is removed/changed.
I would like to see --skip-version-check also in ipa-server-upgrade, for
consistency with ipactl.
In the spec file ipa-server-upgrade is run with --quiet, so why redirect
stdout
to /dev/null?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
Dne 29.4.2015 v 08:45 Martin Kosek napsal(a):
On 04/29/2015 07:34 AM, Jan Cholasta wrote:
Dne 27.4.2015 v 18:23 David Kupka napsal(a):
On 04/27/2015 04:45 PM, Martin Basti wrote:
On 27/04/15 13:38, Martin Basti wrote:
On 23/04/15 12:55, Martin Basti wrote:
On 21/04/15 10:31, Martin Basti wrote:
On 21/04/15 08:12, Jan Cholasta wrote:
Hi,
Dne 15.4.2015 v 16:26 Martin Basti napsal(a):
https://fedorahosted.org/freeipa/ticket/4904
Patches attached.
Also ipa-upgradeconfig part is called as a subprocess. This will be
removed after installer modifications.
This patch may cause temporal upgrade issues (corner cases), until
installer part will be finished.
If somebody will be hit by them, please use --skip-version-check for
ipactl and ipa-server-upgrade.
Regarding that option vs. --force: I think the common assumption is
that --force ignores *all* non-fatal errors, but you break that
assumption in ipactl. IMO --force should both ignore errors in
service startup *and* skip version check, and a new option should
be added to just ignore errors in service startup (e.g.
--ignore-service-failures).
Originally I used --force option to skip detection, but there was
objections against it on list.
However, to have option --force, which set true for both
--ignore-service-failures and --skip-version-check options, might be
better.
ipa-server-upgrade should probably also have --force, even if it
does the same thing as --skip-version-check, again because --force
is common.
This is a weird API:
+if data_upgrade.badsyntax:
+raise admintool.ScriptError(
+'Bad syntax detected in upgrade file(s).', 1)
+elif data_upgrade.upgradefailed:
+raise admintool.ScriptError('IPA upgrade failed.', 1)
+elif data_upgrade.modified:
+self.log.info('Data update complete')
+else:
+self.log.info('Data update complete, no data were
modified')
Why does not IPAUpgrade raise errors instead?
For historical reasons, I can investigate what would break this
change, I will send it in separate patch.
+class IPAVersionError(Exception):
+pass
+
+class PlatformMismatchError(IPAVersionError):
+pass
+
+class DataUpgradeRequiredError(IPAVersionError):
+pass
+
+class DataInNewerVersionError(IPAVersionError):
+pass
I don't like the IPA in IPAVersionError, it does not tell you
much about what kind of version is that. Also data version errors
should only tell you what is wrong, not how you fix it. IMO better
names for these would be e.g. UpgradeVersionError,
UpgradePlatformError, UpgradeDataOlderVersionError,
UpgradeDataNewerVersionError. Similar for store_ipa_version and
check_ipa_version.
Ok.
Why is it not an error if there is no version in check_ipa_version?
IMO it should, even if you then ignore the exception most of the
time.
I can raise error in that case and ignore the exception.
Honza
Martin^2
Updated patches attached.
Updated patches attached
--
Martin Basti
Updated patch attached
Looks good to me and works as expected. Honza, are you OK with the patches?
Some nitpicks:
The command line tool class should be named ServerUpgrade rather than
IPAServerUpgrade for consistency with others.
The deprecated --debug option should not be used in new commands.
Why is --debug option deprecated? I thought we wanted to deprecate --verbose
option as --debug is used in most our CLI tools. Well, except ipa-ldap-updated
which for some reasons marks --debug as deprecated. It does not matter now,
given the command is removed/changed.
AdminTool provides --debug as a deprecated alias for --verbose when a
subclass requests it. It seems the decision to deprecate --debug was
already made back when AdminTool was introduced, so let's trust that
decision.
--
Jan Cholasta
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Suggestion for the A part of IPA
On 04/28/2015 05:58 PM, Innes, Duncan wrote: Folks, The A part of IPA has always been of great interest to me. Our current IPA infrastructure works well at the I P parts, giving us great failover abilities and connectivity through hardware firewalls without punching too many holes. Good to hear :-) We recently also started investigating the Audit capabilities for (notice I write for and not in) IPA. You can check my initial nudge to the freeipa-users list, which was unfortunately with no reply: https://www.redhat.com/archives/freeipa-users/2015-March/msg00940.html For the beginning, I would be interested for your use cases, if you are only looking for a centralized log store, or you are also looking for more analytics in the logs (like what API commands were run, user logins, etc.) or utilization of the server core services (LDAP/Kerberos/DNS/...) Whilst the A part may not be solely about centralised logging, it's the thing I've been looking into recently. To do this I've built a setup around the ELK stack using a pair of Logstash servers and an ElasticSearch cluster of 5 servers (overkill on the ES side perhaps, but this is proof of concept still). To expand on this, I've been looking at running the Logstash serviceon each of our IPA servers as that gives us a failover pair in each part of our network. The Logstash servers then connect to the ES cluster as non-data nodes. Each client has an rsyslog7 (still using RHEL6 at the moment) config that writes sends the logs in JSON format with some extra bespoke fields added (such as Project, Environment, and Use to help us search better). The sending is done in rsyslog's rather clunky failover method to the local pair of Logstash servers (with a third failover being to /dev/null). Ah, so you are running Logstash service on each IPA service? Isn't that too heavyweight? In our tests, we mostly simply wanted just configure rsyslog and get the logs out of the server, to the centralized ELK/REK/EFK servers which did the heavy lifting. After all, the IPA servers may be of different environments (Fedora, RHEL, CentOS, ...) and with different versions of the log processing software. On the REK server (yes, we did not use logstash at the POC), we are able to process the logs (make them structured), store and display them. This allows us do searches like list of admins which added users in the last month. This if course required adding parsing rules to rsyslog to get the structure out of the API logs. Are you using logstash for the parsing or did you not start the parsing part yet? It struck me that this kind of setup might not be too far removed from some of the A part of IPA. The centralized log processing itself is a too big task for IPA itself, it is specialized on other things. But some integration should be added in time, I agree. It may be minimal, from top of my head for example: * Support of (rsyslog) configuration in ipa-client-install or ipa-server-install * Providing the secure, GSSAPI-based log transfer to the IPA clients and ELK/REK/EFK server * Providing parsing templates for rsyslog or base queries for Kibana I'm not good at ASCII flowchart diagrams, so will leave it there for now. The main point of this - does any of this idea sound reasonable to add in to FreeIPA? To me it sounds like a good fit for getting (some) logging data back to a central point. The Logstash indexers currently have a very low load (perhaps due to the incoming data already being JSON) and small memory footprint. They run without issue on our IPA servers. The ES nodes are different and I won't pretent to be any sort of expert in what they do. They load up a bit when I shut 1 of them down, but that's the rebalancing happening. Apologies if this is off topic, or wide of the mark. Cheers Duncan Innes This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -- Manage your subscription for
Re: [Freeipa-devel] [PATCHES 0031-0032] set up a dedicated CCache file for Apache during install/upgrade
On Wed, 2015-04-29 at 09:29 +0200, Martin Babinsky wrote: On 04/29/2015 09:09 AM, Martin Kosek wrote: On 04/28/2015 05:42 PM, Martin Babinsky wrote: The attached patches address https://fedorahosted.org/freeipa/ticket/4973 and implement the solution proposed in Comment 2. Please review the hell out of them. Why did you split the work in 2 patches? It looks like you first did the first approach of modifying httpd.service and then changed your mind and did the ipa-httpd.service approach (which is what we agreed to). I was thinking about it as a two distinct operations (modify existing httpd.service to use KRB5CCNAME and rename httpd.service to ipa-httpd.service). But I can merge them if needed. Also, shouldn't ipa-httpd.service be contained in the package itself, like ipa-dnskeysyncd and httpd.service masked during installation? Also, I do not see any daemon-reload, so I am not sure if systemd would pick up the right configuration in the first install. Martin^2 told me that generating service file from template is evil, so I will put the full service file into init/systemd directory so that it is already present in /etc/systemd/system after rpm install. Next, I was thinking what should be the ideal KRB5CCNAME for the HTTPD service. You chose /tmp/ipa-httpd.ccache, is it the best approach CCACHE type/path we should use? This is mostly question to Simo, his mod_auth_gssapi will consume the ccache. I will ask Simo if there is some preferred way to name CCache files. After discussing with Martin I think we should have only one patch, which should simply change the service unit name used on systemd systems, then provide the new unit file ready made (and installed by RPMs directly). The new unit file should basically just include the original httpd unit file and set KRB5CCNAME to a default of /var/run/httpd/krb5ccache or similar. We should avoid using /tmp if not necessary, even though in most systemd based system it is easy to have private /tmp and the default on Fedora I prefer avoid counting on it, as I am not sure what is the default in systems like debian/ubuntu/suse etc.. For older sysv/rpm based systems we just need to change /etc/sysconfig/httpd I guess. Let's try to be consistent and use the same cache controlled by us on newer and older systems alike. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] behavior change in DNS dynamic updates: #155
Hello, I would like to discuss behavior change which is need for fixing ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/155 PTR record synchronization for A/ record tuple can fail mysteriously Current behavior Currently DNS clients receive SERVFAIL error if A/ record is updated but respective reverse zone is not configured on the same IPA server. See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for details. Change proposal === It seems to me that #155 is not fixable without following behavior change: Client will *not* receive an error if reverse zone is not configured. Would it be okay to do this change and *do not report an error if respective reverse zone is not configured*? I think that it could be actually less confusing because it might be an intentional configuration, too. E.g. the IPA DNS server might be responsible only for 2 zones: - example.com. - 2.0.192.in-addr.arpa. but it does not mean that the zone 'example.com.' cannot contain A/ records belonging to other reverse zones. Currently any attempt to update A/ record which does not belong to reverse zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the update prematurely. Technical details = BIND internally splits update message with multiple requests (e.g. request to add multiple A/ records) to steps where one step is does 1 change in 1 resource record at a time. Our plugin can see only separate steps and not the whole update message. Failure in any step terminates the update completely, rest of the update message is not processed and error is returned to the client. On the other hand, we have no information beforehand if the currently processed step is the last one or not so it is impossible to reliably implement 'this update is the last one, report the error here' logic. I do not see a way to change this without changes to BIND internals and IMHO it is not worth the effort. Thank you for your time! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 29/04/15 07:34, Jan Cholasta wrote:
Dne 27.4.2015 v 18:23 David Kupka napsal(a):
On 04/27/2015 04:45 PM, Martin Basti wrote:
On 27/04/15 13:38, Martin Basti wrote:
On 23/04/15 12:55, Martin Basti wrote:
On 21/04/15 10:31, Martin Basti wrote:
On 21/04/15 08:12, Jan Cholasta wrote:
Hi,
Dne 15.4.2015 v 16:26 Martin Basti napsal(a):
https://fedorahosted.org/freeipa/ticket/4904
Patches attached.
Also ipa-upgradeconfig part is called as a subprocess. This
will be
removed after installer modifications.
This patch may cause temporal upgrade issues (corner cases), until
installer part will be finished.
If somebody will be hit by them, please use
--skip-version-check for
ipactl and ipa-server-upgrade.
Regarding that option vs. --force: I think the common assumption is
that --force ignores *all* non-fatal errors, but you break that
assumption in ipactl. IMO --force should both ignore errors in
service startup *and* skip version check, and a new option should
be added to just ignore errors in service startup (e.g.
--ignore-service-failures).
Originally I used --force option to skip detection, but there was
objections against it on list.
However, to have option --force, which set true for both
--ignore-service-failures and --skip-version-check options, might be
better.
ipa-server-upgrade should probably also have --force, even if it
does the same thing as --skip-version-check, again because --force
is common.
This is a weird API:
+if data_upgrade.badsyntax:
+raise admintool.ScriptError(
+'Bad syntax detected in upgrade file(s).', 1)
+elif data_upgrade.upgradefailed:
+raise admintool.ScriptError('IPA upgrade failed.', 1)
+elif data_upgrade.modified:
+self.log.info('Data update complete')
+else:
+self.log.info('Data update complete, no data were
modified')
Why does not IPAUpgrade raise errors instead?
For historical reasons, I can investigate what would break this
change, I will send it in separate patch.
+class IPAVersionError(Exception):
+pass
+
+class PlatformMismatchError(IPAVersionError):
+pass
+
+class DataUpgradeRequiredError(IPAVersionError):
+pass
+
+class DataInNewerVersionError(IPAVersionError):
+pass
I don't like the IPA in IPAVersionError, it does not tell you
much about what kind of version is that. Also data version errors
should only tell you what is wrong, not how you fix it. IMO better
names for these would be e.g. UpgradeVersionError,
UpgradePlatformError, UpgradeDataOlderVersionError,
UpgradeDataNewerVersionError. Similar for store_ipa_version and
check_ipa_version.
Ok.
Why is it not an error if there is no version in check_ipa_version?
IMO it should, even if you then ignore the exception most of the
time.
I can raise error in that case and ignore the exception.
Honza
Martin^2
Updated patches attached.
Updated patches attached
--
Martin Basti
Updated patch attached
Looks good to me and works as expected. Honza, are you OK with the
patches?
Some nitpicks:
The command line tool class should be named ServerUpgrade rather
than IPAServerUpgrade for consistency with others.
The deprecated --debug option should not be used in new commands.
I would like to see --skip-version-check also in ipa-server-upgrade,
for consistency with ipactl.
In the spec file ipa-server-upgrade is run with --quiet, so why
redirect stdout to /dev/null?
Because --quiet is not quiet enough.
It prints upgrade steps to stdout.
ipa-server-upgrade --quiet
Upgrading IPA:
[1/9]: stopping directory server
[2/9]: saving configuration
[3/9]: disabling listeners
[4/9]: enabling DS global lock
[5/9]: starting directory server
[6/9]: upgrading server
[7/9]: stopping directory server
[8/9]: restoring configuration
[9/9]: starting directory server
Done.
IPA upgrade failed.
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 29/04/15 08:52, Jan Cholasta wrote:
Dne 29.4.2015 v 08:45 Martin Kosek napsal(a):
On 04/29/2015 07:34 AM, Jan Cholasta wrote:
Dne 27.4.2015 v 18:23 David Kupka napsal(a):
On 04/27/2015 04:45 PM, Martin Basti wrote:
On 27/04/15 13:38, Martin Basti wrote:
On 23/04/15 12:55, Martin Basti wrote:
On 21/04/15 10:31, Martin Basti wrote:
On 21/04/15 08:12, Jan Cholasta wrote:
Hi,
Dne 15.4.2015 v 16:26 Martin Basti napsal(a):
https://fedorahosted.org/freeipa/ticket/4904
Patches attached.
Also ipa-upgradeconfig part is called as a subprocess. This
will be
removed after installer modifications.
This patch may cause temporal upgrade issues (corner cases),
until
installer part will be finished.
If somebody will be hit by them, please use
--skip-version-check for
ipactl and ipa-server-upgrade.
Regarding that option vs. --force: I think the common
assumption is
that --force ignores *all* non-fatal errors, but you break that
assumption in ipactl. IMO --force should both ignore errors in
service startup *and* skip version check, and a new option should
be added to just ignore errors in service startup (e.g.
--ignore-service-failures).
Originally I used --force option to skip detection, but there was
objections against it on list.
However, to have option --force, which set true for both
--ignore-service-failures and --skip-version-check options,
might be
better.
ipa-server-upgrade should probably also have --force, even if it
does the same thing as --skip-version-check, again because
--force
is common.
This is a weird API:
+if data_upgrade.badsyntax:
+raise admintool.ScriptError(
+'Bad syntax detected in upgrade file(s).', 1)
+elif data_upgrade.upgradefailed:
+raise admintool.ScriptError('IPA upgrade
failed.', 1)
+elif data_upgrade.modified:
+self.log.info('Data update complete')
+else:
+self.log.info('Data update complete, no data were
modified')
Why does not IPAUpgrade raise errors instead?
For historical reasons, I can investigate what would break this
change, I will send it in separate patch.
+class IPAVersionError(Exception):
+pass
+
+class PlatformMismatchError(IPAVersionError):
+pass
+
+class DataUpgradeRequiredError(IPAVersionError):
+pass
+
+class DataInNewerVersionError(IPAVersionError):
+pass
I don't like the IPA in IPAVersionError, it does not tell you
much about what kind of version is that. Also data version errors
should only tell you what is wrong, not how you fix it. IMO
better
names for these would be e.g. UpgradeVersionError,
UpgradePlatformError, UpgradeDataOlderVersionError,
UpgradeDataNewerVersionError. Similar for store_ipa_version and
check_ipa_version.
Ok.
Why is it not an error if there is no version in
check_ipa_version?
IMO it should, even if you then ignore the exception most of the
time.
I can raise error in that case and ignore the exception.
Honza
Martin^2
Updated patches attached.
Updated patches attached
--
Martin Basti
Updated patch attached
Looks good to me and works as expected. Honza, are you OK with the
patches?
Some nitpicks:
The command line tool class should be named ServerUpgrade rather than
IPAServerUpgrade for consistency with others.
The deprecated --debug option should not be used in new commands.
Why is --debug option deprecated? I thought we wanted to deprecate
--verbose
option as --debug is used in most our CLI tools. Well, except
ipa-ldap-updated
which for some reasons marks --debug as deprecated. It does not
matter now,
given the command is removed/changed.
AdminTool provides --debug as a deprecated alias for --verbose when a
subclass requests it. It seems the decision to deprecate --debug was
already made back when AdminTool was introduced, so let's trust that
decision.
Yes that is reason. I will update design as well
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync
On 03/11/2015 04:20 PM, Jan Cholasta wrote: Hi, Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): On 03/09/2015 12:26 PM, Tomas Babej wrote: Hi, this couple of patches provides a initial implementation of the winsync migration tool: https://fedorahosted.org/freeipa/ticket/4524 Some parts could use some polishing, but this is a sound foundation. Tomas Attaching one more patch to the bundle. This one should make the winsync tool readily available after install. Tomas Nitpicks: The winsync_migrate module should be in ipaserver.install. Also I don't see why it has to be a package when there is just one short file in it. By convention, the AdminTool subclass should be named WinsyncMigrate, or the tool should be named ipa-migrate-winsync. Honza Updated patches attached. Tomas From 399edfdefcb66a613c5c6fa8bcd61f4272d3a9fc Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 29 Apr 2015 08:15:50 +0200 Subject: [PATCH] winsync-migrate: Add initial plumbing --- install/tools/ipa-winsync-migrate | 23 ipaserver/winsync_migrate/__init__.py | 22 ipaserver/winsync_migrate/base.py | 67 +++ 3 files changed, 112 insertions(+) create mode 100755 install/tools/ipa-winsync-migrate create mode 100644 ipaserver/winsync_migrate/__init__.py create mode 100644 ipaserver/winsync_migrate/base.py diff --git a/install/tools/ipa-winsync-migrate b/install/tools/ipa-winsync-migrate new file mode 100755 index ..9eb9a03eb92396c855706e0f85850baece45b27e --- /dev/null +++ b/install/tools/ipa-winsync-migrate @@ -0,0 +1,23 @@ +#! /usr/bin/python2 -E +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. +# + +from ipaserver.winsync_migrate.base import MigrateWinsync + +MigrateWinsync.run_cli() diff --git a/ipaserver/winsync_migrate/__init__.py b/ipaserver/winsync_migrate/__init__.py new file mode 100644 index ..e0da63db3a369adc4a34e8675471929b5839a812 --- /dev/null +++ b/ipaserver/winsync_migrate/__init__.py @@ -0,0 +1,22 @@ +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. +# + + +Base subpackage for winsync-migrate related code. + diff --git a/ipaserver/winsync_migrate/base.py b/ipaserver/winsync_migrate/base.py new file mode 100644 index ..c21a861c2e49b4ab6d9783c117d1e4de126cb0b6 --- /dev/null +++ b/ipaserver/winsync_migrate/base.py @@ -0,0 +1,67 @@ +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. +# + +import krbV +import sys + +from ipalib import api +from ipalib import errors +from ipapython import admintool +from ipapython.dn import DN +from ipapython.ipa_log_manager import log_mgr +from ipaserver.plugins.ldap2 import ldap2 + + +class
Re: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd
On Wed, 2015-04-29 at 19:42 +0200, Martin Babinsky wrote: # NOTE: systemd specific section -/bin/systemctl try-restart httpd.service /dev/null 21 || : +/bin/systemctl try-restart ipa-httpd.service /dev/null 21 || : # END fi Isn't this going to fail on upgrades where you want to move from httpd.service to ipa-httpd.service ? Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd
The attached patch is a merge of PATCHES 0031-0032 incorporating Simo's
and Martin's suggestions (see e.g.
https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html
for reference).
https://fedorahosted.org/freeipa/ticket/4973
--
Martin^3 Babinsky
From 93bbf9f3004279fae53d81d95b60b340bd77f433 Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Tue, 28 Apr 2015 16:24:02 +0200
Subject: [PATCH] provide dedicated ccache file for httpd
httpd service stores Kerberos credentials in kernel keyring which gets
destroyed and recreated during service install/upgrade, causing problems when
the process is run under SELinux context other than 'unconfined_t'. This patch
enables HTTPInstance to set up a dedicated CCache file for Apache to store
credentials.
https://fedorahosted.org/freeipa/ticket/4973
---
freeipa.spec.in| 4 +++-
init/systemd/ipa-httpd.service | 4
ipaplatform/redhat/services.py | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 init/systemd/ipa-httpd.service
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 608242b5adbc43efbbf0ae30a6d7a933bebc1084..3ccd66411808ce204b6d2b084eb44c805a59621a 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -472,6 +472,7 @@ touch %{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so
mkdir -p %{buildroot}%{_unitdir}
install -m 644 init/systemd/ipa.service %{buildroot}%{_unitdir}/ipa.service
install -m 644 init/systemd/ipa_memcached.service %{buildroot}%{_unitdir}/ipa_memcached.service
+install -m 644 init/systemd/ipa-httpd.service %{buildroot}%{_unitdir}/ipa-httpd.service
# END
mkdir -p %{buildroot}/%{_localstatedir}/lib/ipa/backup
%endif # ONLY_CLIENT
@@ -560,7 +561,7 @@ fi
python2 -c import sys; from ipaserver.install import installutils; sys.exit(0 if installutils.is_ipa_configured() else 1); /dev/null 21
if [ $? -eq 0 ]; then
# NOTE: systemd specific section
-/bin/systemctl try-restart httpd.service /dev/null 21 || :
+/bin/systemctl try-restart ipa-httpd.service /dev/null 21 || :
# END
fi
@@ -691,6 +692,7 @@ fi
%attr(644,root,root) %{_unitdir}/ipa-dnskeysyncd.service
%attr(644,root,root) %{_unitdir}/ipa-ods-exporter.socket
%attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service
+%attr(644,root,root) %{_unitdir}/ipa-httpd.service
# END
%dir %{python_sitelib}/ipaserver
%dir %{python_sitelib}/ipaserver/install
diff --git a/init/systemd/ipa-httpd.service b/init/systemd/ipa-httpd.service
new file mode 100644
index ..ef1e6bfda06f1a1d703a174040f1f6e6ea0757c7
--- /dev/null
+++ b/init/systemd/ipa-httpd.service
@@ -0,0 +1,4 @@
+.include /usr/lib/systemd/system/httpd.service
+
+[Service]
+Environment=KRB5CCNAME=/var/run/httpd/krbcache/krb5ccache
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index c9994e409a8a005012c0467c016608b8f689eef1..0537680bb6b3e0cb58df732e0cb390edb73795cb 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -74,6 +74,7 @@ redhat_system_units['ods-enforcerd'] = 'ods-enforcerd.service'
redhat_system_units['ods_enforcerd'] = redhat_system_units['ods-enforcerd']
redhat_system_units['ods-signerd'] = 'ods-signerd.service'
redhat_system_units['ods_signerd'] = redhat_system_units['ods-signerd']
+redhat_system_units['httpd'] = 'ipa-httpd.service'
# Service classes that implement Red Hat OS family-specific behaviour
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] behavior change in DNS dynamic updates: #155
On 29/04/15 15:40, David Kupka wrote: On 04/29/2015 02:27 PM, Petr Spacek wrote: Hello, I would like to discuss behavior change which is need for fixing ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/155 PTR record synchronization for A/ record tuple can fail mysteriously Current behavior Currently DNS clients receive SERVFAIL error if A/ record is updated but respective reverse zone is not configured on the same IPA server. See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for details. Change proposal === It seems to me that #155 is not fixable without following behavior change: Client will *not* receive an error if reverse zone is not configured. Would it be okay to do this change and *do not report an error if respective reverse zone is not configured*? Just for clarification: If any A/ record update failed, server will return SERVFAIL and rollback changes If all A/ records were successfully added, just SRV record is not created by dyndb-ldap, server returns NOERROR nsupdate contains A//PTR record, if PTR record update failed, server will return SERVFAIL and rollback changes. Right? Yes. Client has always chance to check if the reverse records were created or not. Additionally client only tries to add A/ records and doesn't know if there are any reverse zones or not. Yes. Client has no information that PTR records should be created too. We can just shown warning, the client has no reverse record (we need to decide if this is right approach) I think that it could be actually less confusing because it might be an intentional configuration, too. E.g. the IPA DNS server might be responsible only for 2 zones: - example.com. - 2.0.192.in-addr.arpa. but it does not mean that the zone 'example.com.' cannot contain A/ records belonging to other reverse zones. Currently any attempt to update A/ record which does not belong to reverse zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the update prematurely. Technical details = BIND internally splits update message with multiple requests (e.g. request to add multiple A/ records) to steps where one step is does 1 change in 1 resource record at a time. Our plugin can see only separate steps and not the whole update message. Failure in any step terminates the update completely, rest of the update message is not processed and error is returned to the client. On the other hand, we have no information beforehand if the currently processed step is the last one or not so it is impossible to reliably implement 'this update is the last one, report the error here' logic. I do not see a way to change this without changes to BIND internals and IMHO it is not worth the effort. Thank you for your time! CCing Jakub as this can hit SSSD. Martin^2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0230] Server upgrade: fix comment in ldapupdater
On 04/28/2015 02:48 PM, Martin Basti wrote: On 27/04/15 18:42, David Kupka wrote: On 04/16/2015 05:14 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4904 Patch attached I guess the rest of the comment is also outdated. Can you update it, too? Updated patch attached. ACK. -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] behavior change in DNS dynamic updates: #155
On 04/29/2015 02:27 PM, Petr Spacek wrote: Hello, I would like to discuss behavior change which is need for fixing ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/155 PTR record synchronization for A/ record tuple can fail mysteriously Current behavior Currently DNS clients receive SERVFAIL error if A/ record is updated but respective reverse zone is not configured on the same IPA server. See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for details. Change proposal === It seems to me that #155 is not fixable without following behavior change: Client will *not* receive an error if reverse zone is not configured. Would it be okay to do this change and *do not report an error if respective reverse zone is not configured*? Yes. Client has always chance to check if the reverse records were created or not. Additionally client only tries to add A/ records and doesn't know if there are any reverse zones or not. I think that it could be actually less confusing because it might be an intentional configuration, too. E.g. the IPA DNS server might be responsible only for 2 zones: - example.com. - 2.0.192.in-addr.arpa. but it does not mean that the zone 'example.com.' cannot contain A/ records belonging to other reverse zones. Currently any attempt to update A/ record which does not belong to reverse zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the update prematurely. Technical details = BIND internally splits update message with multiple requests (e.g. request to add multiple A/ records) to steps where one step is does 1 change in 1 resource record at a time. Our plugin can see only separate steps and not the whole update message. Failure in any step terminates the update completely, rest of the update message is not processed and error is returned to the client. On the other hand, we have no information beforehand if the currently processed step is the last one or not so it is impossible to reliably implement 'this update is the last one, report the error here' logic. I do not see a way to change this without changes to BIND internals and IMHO it is not worth the effort. Thank you for your time! -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] behavior change in DNS dynamic updates: #155
On 29/04/15 16:05, Martin Basti wrote: On 29/04/15 15:40, David Kupka wrote: On 04/29/2015 02:27 PM, Petr Spacek wrote: Hello, I would like to discuss behavior change which is need for fixing ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/155 PTR record synchronization for A/ record tuple can fail mysteriously Current behavior Currently DNS clients receive SERVFAIL error if A/ record is updated but respective reverse zone is not configured on the same IPA server. See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for details. Change proposal === It seems to me that #155 is not fixable without following behavior change: Client will *not* receive an error if reverse zone is not configured. Would it be okay to do this change and *do not report an error if respective reverse zone is not configured*? Just for clarification: If any A/ record update failed, server will return SERVFAIL and rollback changes If all A/ records were successfully added, just SRV record is not created by dyndb-ldap, server returns NOERROR s/SRV/PTR sorry nsupdate contains A//PTR record, if PTR record update failed, server will return SERVFAIL and rollback changes. Right? Yes. Client has always chance to check if the reverse records were created or not. Additionally client only tries to add A/ records and doesn't know if there are any reverse zones or not. Yes. Client has no information that PTR records should be created too. We can just shown warning, the client has no reverse record (we need to decide if this is right approach) I think that it could be actually less confusing because it might be an intentional configuration, too. E.g. the IPA DNS server might be responsible only for 2 zones: - example.com. - 2.0.192.in-addr.arpa. but it does not mean that the zone 'example.com.' cannot contain A/ records belonging to other reverse zones. Currently any attempt to update A/ record which does not belong to reverse zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the update prematurely. Technical details = BIND internally splits update message with multiple requests (e.g. request to add multiple A/ records) to steps where one step is does 1 change in 1 resource record at a time. Our plugin can see only separate steps and not the whole update message. Failure in any step terminates the update completely, rest of the update message is not processed and error is returned to the client. On the other hand, we have no information beforehand if the currently processed step is the last one or not so it is impossible to reliably implement 'this update is the last one, report the error here' logic. I do not see a way to change this without changes to BIND internals and IMHO it is not worth the effort. Thank you for your time! CCing Jakub as this can hit SSSD. Martin^2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0047] Unsaved changes dialog inconsistent
- Original Message - On 04/27/2015 03:03 PM, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4926 Thanks, Gabe PatternFly has new recommendations for terminology and wording [1]. I'm not entirely sure if the usage of 'save' here is good. PF defines 'edit' as the recommended term. The page doesn't say if 'save' is not recommended, though. Save seems to me as a confirmation of editing. Yes I think save would be best here based on the message given. Thanks for checking out the Terminology screen! Kyle, could you advise what is the best term for reflecting user changes and for confirmation of this action? Technical notes: 1. it would be better to add a new string and then use it in the button instead of having 'Save' text for '@i18n:buttons.update' definition. 2. String changes in internal.py should be also reflected in install/ui/test/data/ipa_init.json (for static web ui demo). 3. optional: in addition to text change, buttons and related actions could also be renamed (same reasons as in 1). It's more proper but much more complicated. [1] https://www.patternfly.org/styles/terminology-and-wording/#action-labels -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command
On 29/04/15 13:22, Martin Kosek wrote:
On 04/29/2015 12:59 PM, Martin Kosek wrote:
On 04/29/2015 12:50 PM, Martin Basti wrote:
On 29/04/15 12:39, Martin Kosek wrote:
On 04/29/2015 12:15 PM, Martin Basti wrote:
On 29/04/15 08:52, Jan Cholasta wrote:
Dne 29.4.2015 v 08:45 Martin Kosek napsal(a):
On 04/29/2015 07:34 AM, Jan Cholasta wrote:
...
The command line tool class should be named ServerUpgrade rather than
IPAServerUpgrade for consistency with others.
The deprecated --debug option should not be used in new commands.
Why is --debug option deprecated? I thought we wanted to deprecate --verbose
option as --debug is used in most our CLI tools. Well, except
ipa-ldap-updated
which for some reasons marks --debug as deprecated. It does not matter now,
given the command is removed/changed.
AdminTool provides --debug as a deprecated alias for --verbose when a
subclass requests it. It seems the decision to deprecate --debug was already
made back when AdminTool was introduced, so let's trust that decision.
Yes that is reason.
No, it's not.
I will update design as well
Nope. This decision was never made this way, AFAIR. --debug is what all the
main tools (ipa-server-install, ipa-replica-install, ipa-client-install) use
and we never agreed that we want to change it.
In fact, I think I remember some discussion from Devconf.cz time, when we
mentioned that the ipa-ldap-updater has it the deprecated status wrong way,
that we want --debug. CCing Simo since he may have been in the conversation.
http://freeipa.org/page/V3/Logging_and_output
In commands that currently have it, the `-d, --debug` option will become a
deprecated alias for --verbose.
I see, I must somehow missed that aspect of the miniframework. Well, question
is - is it really a good decision and thing we should do?
I.e. slowly moving towards --verbose option, deprecating --debug, given we use
--debug in most commands and people are using it? This could cause lot of
unnecessary churn in stable distributions that would wish to rebase to FreeIPA,
like CentOS or RHEL - and for what reason?
I will be against removing --debug option from the main commands unless there
is a very good reason and justification to do so.
Martin
I talked to Martin in person. If --debug option is not removed and is kept in
the old commands and you really want to go with the --verbose option crusade, I
can live with it.
Martin
Updated patches attached.
* Removed --debug version
* I also added log message that version check was skipped
--
Martin Basti
From aa1aaa52060f4927f4f8e20a80f8735be7a1a3a3 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Thu, 2 Apr 2015 14:14:15 +0200
Subject: [PATCH 1/3] Server Upgrade: ipa-server-upgrade command
https://fedorahosted.org/freeipa/ticket/4904
---
freeipa.spec.in | 2 +
install/tools/Makefile.am | 1 +
install/tools/ipa-server-upgrade| 12 ++
install/tools/man/Makefile.am | 1 +
install/tools/man/ipa-server-upgrade.1 | 40 ++
ipaserver/install/ipa_server_upgrade.py | 72 +
6 files changed, 128 insertions(+)
create mode 100644 install/tools/ipa-server-upgrade
create mode 100644 install/tools/man/ipa-server-upgrade.1
create mode 100644 ipaserver/install/ipa_server_upgrade.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 608242b5adbc43efbbf0ae30a6d7a933bebc1084..c661fe574464fdba1b1a8c64710d44a012ec8ede 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -660,6 +660,7 @@ fi
%{_sbindir}/ipa-replica-manage
%{_sbindir}/ipa-csreplica-manage
%{_sbindir}/ipa-server-certinstall
+%{_sbindir}/ipa-server-upgrade
%{_sbindir}/ipa-ldap-updater
%{_sbindir}/ipa-otptoken-import
%{_sbindir}/ipa-compat-manage
@@ -804,6 +805,7 @@ fi
%{_mandir}/man1/ipa-replica-prepare.1.gz
%{_mandir}/man1/ipa-server-certinstall.1.gz
%{_mandir}/man1/ipa-server-install.1.gz
+%{_mandir}/man1/ipa-server-upgrade.1.gz
%{_mandir}/man1/ipa-dns-install.1.gz
%{_mandir}/man1/ipa-ca-install.1.gz
%{_mandir}/man1/ipa-kra-install.1.gz
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index b791a8c748a18602f88522c3a0e3d74499700ae0..e5d45c47966a503da9f25aec13175793a36962e4 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -16,6 +16,7 @@ sbin_SCRIPTS = \
ipa-replica-manage \
ipa-csreplica-manage \
ipa-server-certinstall \
+ ipa-server-upgrade \
ipactl \
ipa-compat-manage \
ipa-nis-manage \
diff --git a/install/tools/ipa-server-upgrade b/install/tools/ipa-server-upgrade
new file mode 100644
index ..781b0d3dbcf2b1b5493126ad3d7eb74032864dbb
--- /dev/null
+++ b/install/tools/ipa-server-upgrade
@@ -0,0 +1,12 @@
+#!/usr/bin/python2
+#
+# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
+#
+
+# Documentation can be found at:
+# http://freeipa.org/page/LdapUpdate
+#
Re: [Freeipa-devel] behavior change in DNS dynamic updates: #155
On 29.4.2015 16:06, Martin Basti wrote: On 29/04/15 16:05, Martin Basti wrote: On 29/04/15 15:40, David Kupka wrote: On 04/29/2015 02:27 PM, Petr Spacek wrote: Hello, I would like to discuss behavior change which is need for fixing ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/155 PTR record synchronization for A/ record tuple can fail mysteriously Current behavior Currently DNS clients receive SERVFAIL error if A/ record is updated but respective reverse zone is not configured on the same IPA server. See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for details. Change proposal === It seems to me that #155 is not fixable without following behavior change: Client will *not* receive an error if reverse zone is not configured. Would it be okay to do this change and *do not report an error if respective reverse zone is not configured*? Just for clarification: If any A/ record update failed, server will return SERVFAIL and rollback changes If all A/ records were successfully added, just SRV record is not created by dyndb-ldap, server returns NOERROR s/SRV/PTR sorry Yes, this is correct. It seems like agreement so I will fix #155 as described above. It turned out that #155 is a prerequisite for #151. I really like spaghetti! ;-) Petr^2 Spacek nsupdate contains A//PTR record, if PTR record update failed, server will return SERVFAIL and rollback changes. Right? Yes. Client has always chance to check if the reverse records were created or not. Additionally client only tries to add A/ records and doesn't know if there are any reverse zones or not. Yes. Client has no information that PTR records should be created too. We can just shown warning, the client has no reverse record (we need to decide if this is right approach) I think that it could be actually less confusing because it might be an intentional configuration, too. E.g. the IPA DNS server might be responsible only for 2 zones: - example.com. - 2.0.192.in-addr.arpa. but it does not mean that the zone 'example.com.' cannot contain A/ records belonging to other reverse zones. Currently any attempt to update A/ record which does not belong to reverse zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the update prematurely. Technical details = BIND internally splits update message with multiple requests (e.g. request to add multiple A/ records) to steps where one step is does 1 change in 1 resource record at a time. Our plugin can see only separate steps and not the whole update message. Failure in any step terminates the update completely, rest of the update message is not processed and error is returned to the client. On the other hand, we have no information beforehand if the currently processed step is the last one or not so it is impossible to reliably implement 'this update is the last one, report the error here' logic. I do not see a way to change this without changes to BIND internals and IMHO it is not worth the effort. Thank you for your time! CCing Jakub as this can hit SSSD. Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd
Hi, Dne 29.4.2015 v 19:42 Martin Babinsky napsal(a): The attached patch is a merge of PATCHES 0031-0032 incorporating Simo's and Martin's suggestions (see e.g. https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html for reference). https://fedorahosted.org/freeipa/ticket/4973 IMHO we should set the environment variable in /etc/systemd/system/httpd.service, instead of providing a new service file, because we are just changing configuration, not creating a new concurrent httpd instance, as is the case with ipa-memcached, and also not using alternative httpd implementation which masks the current one, as is the case with bind-pkcs11. It would simplify the whole thing significantly and it's even recommended in httpd.service to do so: # For example, to pass additional options (for instance, -D definitions) to the # httpd binary at startup, you need to create a file named # /etc/systemd/system/httpd.service containing: # .include /lib/systemd/system/httpd.service # [Service] # Environment=OPTIONS=-DMY_DEFINE (BTW I wonder why /etc/sysconfig/httpd support was removed from httpd in Fedora (http://pkgs.fedoraproject.org/cgit/httpd.git/commit/?id=0b19f7b6e1a47c6167a8ab43b4a9d1e759b54721), it seems like a better place to customize environment variables, rather than having to create a modified service file...) Anyway, I would prefer if we set it in a way that works on non-systemd distros as well. Can't we just set GssapiCredStore ccache:FILE:/var/run/httpd/krbcache/krb5ccache in /etc/httpd/conf.d/ipa.conf? Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
