Re: [Freeipa-devel] Feature template - proposed changes
On 03/04/2016 03:59 PM, Petr Spacek wrote: > On 4.3.2016 15:23, Martin Kosek wrote: >> On 03/04/2016 03:11 PM, Petr Spacek wrote: >>> Hello, >>> >>> I've updated Feature template to make sure that important the design >>> decisions >>> are recorded somewhere. >>> >>> Of course all this is open for discussion. I did this soon because I believe >>> that it is better to actually see how it looks like instead of discussing >>> vaporware. Wiki has revert button if necessary, feel free to use it. >>> >>> New texts: >>> http://www.freeipa.org/page/Feature_template#Design_Assumptions >> >> Looks good to me. >> >>> http://www.freeipa.org/page/Feature_template#Use_Cases >> >> Does not look good to me. Practical examples of how features is used is in >> How >> to Test section, ideally organized by Use Cases, like in >> http://www.freeipa.org/page/V4/User_Certificates#How_to_Test >> >> If we start adding gory details and examples right in Use Cases section, we >> would kill the clarity of that section that intends to just give you overview >> of the use cases. > > Okay, now I understand that. > Funnily enough the only thing I changed is addition of bullet "* Explicitly > list use cases which were considered but will not supported for some reason. > Include the reason, too ;-)" > > The text you are criticizing is there from the very first version of the page > [2012-07-24T21:09:49 as can be seen on > http://www.freeipa.org/index.php?title=Feature_template=5161]. Heh, sorry the extra rant then - I will therefore blame Rob instead ;-) In all seriousness, we should clarify that in this Feature template improvement session. > >> I would rather imagine something like >> >> http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authentication_on_Selected_System >> >> which is an impromptu format for the new User Story based approach. The >> expectations is that rest of the page will then work with these User >> Stories/Use Cases, whether it is Design, How To Test, UI examples or Test >> Plan. > > Agreed. > > >>> I also did one unrelated change: >>> Now "Feature Management" chapter precedes "Design" chapter with all the gory >>> details. This should make the page more useful for random users who find it >>> using a search engine. >>> >>> Intents: >>> 1. Consider usability *very* early in the design process. >>> 2. Think about LDAP schema support for UI workflows very early. >> >> These are good intents. However, while I agree with the intents, I am curious >> how this is supposed to work, because the CLI/UI often works with the terms >> that are being defined in Design. >> >> See for example here: >> http://www.freeipa.org/page/V4/User_Certificates#Feature_Management >> It already assumes you know some parts of the design, like matching >> attribute. >> >> Or: >> http://www.freeipa.org/page/V4/OTP#Feature_Management >> It already assumes you know what OTP token is, what Radius Proxy server is >> and >> how it relates, etc. > > Well, that points to an interesting problem of user interface design. > > Is the user assumed to read the *design* page before using the feature (so he > knows the terms as you pointed out)? If it is true then we failed > spectacularly at providing usable user interfaces. > > Looking at > https://www.nngroup.com/articles/ten-usability-heuristics/ > second principle: > > # Match between system and the real world > ## The system should speak the users' language, with words, phrases and > concepts familiar to the user, rather than system-oriented terms. Follow > real-world conventions, making information appear in a natural and logical > order. > > > My understanding to this is that terms should be 'the usual' terms used in > given field. FreeIPA did not invent neither of OTP, RADIUS, DNS, PKI, AD etc. > > Interface should be self-describing. If it is not then we failed. If there is > hard to understand but standard terminology, link to an external article and > do not spend time on describing it 25th time (most likely using slightly > inconsistent terms). > > Obviously there will be exceptions but wiki has hyperlinks so this can be > handled if absolutely necessary. Hmm, that's a good point. I am not completely sold yet as I kind of liked the original logical flow of the design page. But I think we will see that on the first non-trivial example of design page. Maybe you could hane the DNS Location design page updated with your proposed flow, so that we see if it indeed makes sense? That design page can be surely considered non-trivial. >>> DNS locations proved that UI is a nightmare which is better to think about >>> in >>> the very beginning, even before thinking about LDAP schema. >>> >>> I hope it will help in long term. >> >> While it may make sense to *think* about the interfaces first, why does it >> also >> have to be in the design page as the first thing, given it breaks the natural >> and logical flow of the text? > > In my eyes this is more logical and
Re: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install
On 3.3.2016 08:18, Jan Cholasta wrote:
On 2.3.2016 22:15, Martin Štefany wrote:
Hi,
On St, 2016-03-02 at 17:51 +0100, Martin Basti wrote:
On 27.02.2016 21:19, Martin Štefany wrote:
Hi,
I did as Jan suggested, everything is now a new command 'ipa-
sshupdate',
(so it's based on Jan's 'ipa-certupdate', yeah, a bit of copy-
paste),
rest is based on ipa-client-install's code. I'm not sure if this is
correct, but you might want to change ipa-client-install to just
'import
ipaclient.ipa_sshupdate' for ssh update, or not - I'm not sure how
this
is compatible with 'code deduplication', 're-usage', etc.
Another open point from my side is PEP8 compliance, I've ran the new
code through pep8 utility with defaults and it's 'OK'. But so is
code in
my employer's project and they look slightly 'different', mainly for
brackets, strings, etc. Please, have a look to that, too, I'm happy
for
any guidance.
Martin
On Št, 2016-02-25 at 14:36 +0100, Jan Cholasta wrote:
Hi,
On 25.2.2016 14:23, Martin Basti wrote:
On 22.02.2016 22:13, Martin Štefany wrote:
Hi,
please, review the attached patch which adds --ssh-update to
ipa-
client-
install.
Ticket:https://fedorahosted.org/freeipa/ticket/2655
Hello,
thank you for your patch.
Please attach a patch as a file next time.
I have doubts that this should be part of ipa-client-install,
this
needs
a broader discussion.
+1, I think it should be a separate command (ignore my earlier
suggestion from Trac to incorporate this into ipa-client-install,
I
was
young and stupid).
See client/ipa-certupdate and ipaclient/ipa_certupdate.py for an
example
of how such a command should be implemented.
Code comments inline:
---
Martin
From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17
00:00:00 2001
From: Martin Stefany
Date: Mon, 22 Feb 2016 20:58:13 +
Subject: [PATCH] Add new parameter --ssh-update to ipa-client-
install
Add a new parameter '--ssh-update' which can be used later
after
freeipa
client is installed to update SSH hostkeys and SSHFP DNS
records
for
host.
https://fedorahosted.org/freeipa/ticket/2655
---
ipa-client/ipa-install/ipa-client-install | 102
+-
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-
client/ipa-
install/ipa-client-install
index
789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bdda
da89
a3b151
33e398ca50 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1
CLIENT_NOT_CONFIGURED = 2
CLIENT_ALREADY_CONFIGURED = 3
CLIENT_UNINSTALL_ERROR = 4 # error after restoring
files/state
+CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH
public
keys
def parse_options():
def validate_ca_cert_file_option(option, opt, value,
parser):
@@ -215,6 +216,12 @@ def parse_options():
"be run with --
unattended
option")
parser.add_option_group(uninstall_group)
+sshupdate_group = OptionGroup(parser, "SSH key update
options")
+sshupdate_group.add_option("--ssh-update",
dest="ssh_update",
+ action="store_true", default=False,
+ help="update local host's SSH public
keys
in host
entry and DNS.")
+parser.add_option_group(sshupdate_group)
+
options, args = parser.parse_args()
safe_opts = parser.get_safe_opts(options)
@@ -840,6 +847,92 @@ def uninstall(options, env):
return rv
+def sshupdate(options, env):
+if not is_ipa_client_installed():
+root_logger.error("IPA client is not configured on
this
system.")
+return CLIENT_NOT_CONFIGURED
+
+api.bootstrap(context='cli_installer',
debug=options.debug)
+api.finalize()
+if 'config_loaded' not in api.env:
+root_logger.error("Failed to initialize IPA API.")
+return CLIENT_SSHUPDATE_ERROR
+
+# Now, let's try to connect to the server's RPC interface
+connected = False
+try:
+api.Backend.rpcclient.connect()
+connected = True
+root_logger.debug("Try RPC connection")
+api.Backend.rpcclient.forward('ping')
+except errors.KerberosError as e:
+if connected:
+api.Backend.rpcclient.disconnect()
+root_logger.info(
+"Cannot connect to the server due to Kerberos
error:
%s. "
+"Trying with delegate=True", e)
+try:
+api.Backend.rpcclient.connect(delegate=True)
+root_logger.debug("Try RPC connection")
+api.Backend.rpcclient.forward('ping')
+
+root_logger.info("Connection with delegate=True
successful")
+
+# The remote server is not capable of Kerberos
S4U2Proxy
+# delegation. This features is implemented in IPA
server
+# version 2.2 and higher
+root_logger.warning(
+"Target IPA server has a lower version than
the
enrolled "
+
Re: [Freeipa-devel] Design review request: RFC 2818 certificate compliance
Hi, On 29.2.2016 07:59, Fraser Tweedale wrote: Hi all (especially those interested in certificates), Please provide early review of my design for RFC 2818 compliance which will address the following tickets: - #4970 Server certificate profile should always include a Subject Alternate name for the host - #5706 [RFE] Support SAN-only certificates http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance The design is a WIP and there is no code for it yet. Looking for feedback and (hopefully) validation of the approach before committing cycles to implementing new profile components in Dogtag. 1) Do wildcard certificates need special handling? There is no mention of them in the design doc. 2) Should we accept invalid CSR where CN length is greater than 64? I wouldn't be surprised if these existed in the wild. 3) Sometimes it is not clear which parts belong to Dogtag and which to IPA itself. For example the upgrade section - I assume Dogtag should update registry.cfg and IPA caIPAserviceCert profile, but it is not clearly stated anywhere. 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] [PATCH 0404] ipalib: Fix user certificate docstrings
On Fri, Mar 04, 2016 at 12:49:46PM +0100, Tomas Babej wrote: > Hi, > > this fixes incorrect usercertificate attribute docstrings in several IPA > objects. > > Tomas > ACK. -- 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
