Re: [Freeipa-users] Alpha 2 Bugs or Misconfigurations?
Steven Whately wrote: On Fedora 12, I un-installed 1.2 and then installed 1.9. My clients could not log in. The server was logging the following message: sssd_be: GSSAPI Error: The referenced context has expired (Unknown error) Hmm, is the time on the client close to the time on the IPA server? (within 5 min) Not being able to resolve the message I ran: ipa-client-install --uninstall ipa-client-install --no-sssd With this second command I got: Joining realm failed: Host is already joined. Then I noticed that files like nsswitch.conf had not been updated. So I ran: ipa host-del ClientHostname ipa-client-install --no-sssd Yeah, the second time the installation was aborted, hence no nsswitch.conf updating. I guess we could make that clearer. The reason for this is because a lot is stored on the server when you join a client. Re-enrollment requires a new keytab to be generated and new server certificate issued. Currently the uninstaller doesn't remove the host (we'd have to require admin privs to run the uninstaller which seemed a bit draconian). Thankfully this time nsswitch.conf got updated and I now have a working system. It would be nice if ipa-client-install still updated the client files even if the client had been previously added. Well, in the sssd case you'd probably still be left in a bogus state. If using nss_ldap then we might be able to do this but the client machine would be in an iffy state which would likely cause problems later on (like sshd not working). I very happy that I can now see what's going on with this important product. I did not want to miss out on what the freeipa team was working on. Regards Steve Thanks for looking at it. I'm totally open to suggestions if there is a more graceful way to handle client enrollment/unenrollment/re-enrollment. cheers rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Alpha 2 Bugs or Misconfigurations?
If you can summarize your thoughts about the UI in a bulleted list and just send it out would be better. Ok, here goes: * The context sensitive search and great and intuitive but it may also be useful to have a global search that can return results from more than one context. Say I want to find all records that relate to ryan, I could perform a global search on this term and get results from user accounts, automounts, groups, HBACs, etc. all on the same page Right now, I'd have to search for ryan several times on several pages, making note of search results from each page to keep track of all of it. * The button labels are logical to me but perhaps View or Show are better labels for the current Retrieve button, although this is entirely minor and it is certainly not a problem to understand the functionality of the button as-is. Consider this mostly irrelevant. * I like the double-click to Retrieve functionality. It's minor but helps reduce the amount of mouse movement necessary to view a record in detail and makes the UI more desktop-like. * When viewing a record, the Close button is on the far right and the Update and Delete buttons are on the left. I like how that keeps the action buttons separate from the non-action buttons. However, in the Update page, the Cancel button is on the left and the Update button is on the right. It's just a minor layout thing, but keeping the action and non-action buttons on the same side for every page would be more consistent. I found my mouse going to the wrong side sometimes as a result of this, depending on whether I was viewing or updating data. * Sorting by column is a good must-have feature for when looking at a lot of records. Can we expect this functionality to be extended to all columns that will eventually be displayed? It appears right now that more columns will be used in the future to display more information about each record without having to retrieve it and thus extending the column sorting to all columns would be useful. * I don't mind the switching between list and view modes as it currently is but I could potentially be faster to navigate the records by having both list and view visible at the same time. You could just perform a single click on the list to update the view with whatever record was clicked on. I don't know if this would make the best use of screen real-estate or not and I don't really have a strong opinion on it either way right now. * If the separate of list/view model is maintained, all the empty white space currently on the view/update pages could be used to display context-sensitive help and detailed descriptions of each field. This would not only help administrators determine the correct fields in which to enter the necessary details, but also provide information on the expected format of the input or even a list of valid inputs for fields where the input is only going to be one of several possible values. Right now, I'm finding myself having to look up the Administration guide a bunch to remember exactly what each field represents and what to enter into that field to produce my desired end result. Of course, some fields are obvious simply by their label, but not all of them currently are. I applaud the overall effort thus far but I fear I'm the wrong person to be asking for HCI/UI feedback so hopefully more people are sending their ideas, suggestions and feedback as well! Thank you again for you help and interest. No problem ;) --Ryan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Alpha 2 Bugs or Misconfigurations?
Ryan Thomson wrote: If you can summarize your thoughts about the UI in a bulleted list and just send it out would be better. Ok, here goes: * The context sensitive search and great and intuitive but it may also be useful to have a global search that can return results from more than one context. Say I want to find all records that relate to ryan, I could perform a global search on this term and get results from user accounts, automounts, groups, HBACs, etc. all on the same page Right now, I'd have to search for ryan several times on several pages, making note of search results from each page to keep track of all of it. * The button labels are logical to me but perhaps View or Show are better labels for the current Retrieve button, although this is entirely minor and it is certainly not a problem to understand the functionality of the button as-is. Consider this mostly irrelevant. * I like the double-click to Retrieve functionality. It's minor but helps reduce the amount of mouse movement necessary to view a record in detail and makes the UI more desktop-like. * When viewing a record, the Close button is on the far right and the Update and Delete buttons are on the left. I like how that keeps the action buttons separate from the non-action buttons. However, in the Update page, the Cancel button is on the left and the Update button is on the right. It's just a minor layout thing, but keeping the action and non-action buttons on the same side for every page would be more consistent. I found my mouse going to the wrong side sometimes as a result of this, depending on whether I was viewing or updating data. * Sorting by column is a good must-have feature for when looking at a lot of records. Can we expect this functionality to be extended to all columns that will eventually be displayed? It appears right now that more columns will be used in the future to display more information about each record without having to retrieve it and thus extending the column sorting to all columns would be useful. * I don't mind the switching between list and view modes as it currently is but I could potentially be faster to navigate the records by having both list and view visible at the same time. You could just perform a single click on the list to update the view with whatever record was clicked on. I don't know if this would make the best use of screen real-estate or not and I don't really have a strong opinion on it either way right now. * If the separate of list/view model is maintained, all the empty white space currently on the view/update pages could be used to display context-sensitive help and detailed descriptions of each field. This would not only help administrators determine the correct fields in which to enter the necessary details, but also provide information on the expected format of the input or even a list of valid inputs for fields where the input is only going to be one of several possible values. Right now, I'm finding myself having to look up the Administration guide a bunch to remember exactly what each field represents and what to enter into that field to produce my desired end result. Of course, some fields are obvious simply by their label, but not all of them currently are. I applaud the overall effort thus far but I fear I'm the wrong person to be asking for HCI/UI feedback so hopefully more people are sending their ideas, suggestions and feedback as well! Thank you again for you help and interest. No problem ;) --Ryan This is a great feedback! Thank you for your time! -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Alpha 2 Bugs or Misconfigurations?
Unfortunately this might be one of many cases where the UI just does not work yet. There are some patches pending but we decided not to apply them since they are big and could cause side effects. The UI that you see is more a declaration of the direction of the UI rather than a working functionality. It has a lot of glitches we will be cleaning in the upcoming month leading to Beta. Thanks for the information. Good to know I'm not just doing something obviously wrong right now. Should I be filing bug reports for these kinds of issues at this time or wait until further releases when some of the pending patches have been applied? I guess the main goal at the moment is answering the questions like: a) Is the whole model of the list-select-do like it was in old dialog boxes is the right model? b) Do the buttons make sense? Does their meaning makes sense? c) Should we pre-fill the lists automatically (like it is done now) or require search first? I much prefer listing items automatically but I could see this being problematic in huge installations of there is no paging functionality when you reach over X number of records. d) Is it Ok to switch back and forth between the list view and item view or we should combine them in some way? And many more... Ideas and comment are always welcome! Thank you for looking into this. Sorry if we did not meet your expectations. I'll spend more time with the UI tomorrow and see if I can get a feel for the other questions you're looking for feedback on. --Ryan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
