[389-users] Issues related to the Sudoers. Not working..
Hi I am find problems trying to configure the sudoers on ds-389... This is the far I have reached but still is not working... I cannot still download any rule at all the user username belongs to group1 is there anything I might be missing at all? Sudoers Configuration in ds-389 --- dn: ou=SUDOers,dc=companyname,dc=com objectClass: top objectClass: OrganizationalUnit ou: SUDOers dn: cn=group1,ou=SUDOers,dc=companyname,dc=com objectClass: top objectClass: sudoRole cn: sudogrp sudoUser: %group1 sudoHost: ALL sudoCommand: /usr/bin/sudo sudoCommand: /usr/bin/su /etc/sssd/sssd.conf == [domain/companyname] krb5_realm = companyname.com krb5_server = ldapserver.eweprod.companyname.com enumerate = true auth_provider = ldap id_provider = ldap sudo_provider = ldap case_sensitive = False debug_level = 5 chpass_provider = ldap #pam_password = md5 #chpass_provider = krb5 cache_credentials = False ldap_user_name = uid ldap_default_authtok_type = password ldap_search_base = dc=companyname,dc=com ldap_user_search_base = ou=companynameAccts,DC=companyname,DC=com ldap_group_search_base = OU=companynameGroups,dc=companyname,dc=com ldap_default_bind_dn = uid=linuxuser,ou=companynameaccts,dc=companyname,dc=com ldap_uri = ldaps://ldapserver.eweprod.companyname.com ldap_sudo_search_base = ou=SUDOers,dc=companyname,dc=com ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = demand ldap_schema = rfc2307bis ldap_id_use_start_tls = False ldap_default_authtok = password access_provider = simple simple_allow_groups = tester1, tester2 use_host_filter = false #sudo ldap_sudo_full_refresh_interval=86400 ldap_sudo_smart_refresh_interval=3600 [sssd] config_file_version = 2 services = nss, pam, sudo domains = companyname debug_level = 5 [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] [sudo] debug_level = 6 = /etc/pam.d/sudo --- #%PAM-1.0 auth sufficientpam_ldap.so uth required pam_unix.so try_first_pass auth required pam_nologin.so auth include system-auth accountinclude system-auth password include system-auth sessionoptional pam_keyinit.so revoke sessionrequired pam_limits.so -- Output log: -- (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [username] from [ALL] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [username] from [companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=username)(sudoUser=#1000)(sudoUser=%group1)(sudoUser=+*))((dataExpireTimestamp=1402933038)))] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(name=defaults)))] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [default options@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [username] from [ALL] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [username] from [companyname] (Mon Jun 16 11:37:18
Re: [389-users] Issues related to the Sudoers. Not working..
Sorry Guys I saw the light after hours... Solution: for pam.d/sudo #%PAM-1.0 auth include system-auth accountinclude system-auth password include system-auth sessionoptional pam_keyinit.so revoke sessionrequired pam_limits.so And for the ou=SUDOers APPLY read policies for the relevant users or groups!! (That is the reason why it could not download anything from that group. The user/group which run the bindings on sssd was NOT able of reading that OU!!) Thanks very much guys On 2014-06-16 08:47, g.fer.or...@unicyber.co.uk wrote: Hi I am find problems trying to configure the sudoers on ds-389... This is the far I have reached but still is not working... I cannot still download any rule at all the user username belongs to group1 is there anything I might be missing at all? Sudoers Configuration in ds-389 --- dn: ou=SUDOers,dc=companyname,dc=com objectClass: top objectClass: OrganizationalUnit ou: SUDOers dn: cn=group1,ou=SUDOers,dc=companyname,dc=com objectClass: top objectClass: sudoRole cn: sudogrp sudoUser: %group1 sudoHost: ALL sudoCommand: /usr/bin/sudo sudoCommand: /usr/bin/su /etc/sssd/sssd.conf == [domain/companyname] krb5_realm = companyname.com krb5_server = ldapserver.eweprod.companyname.com enumerate = true auth_provider = ldap id_provider = ldap sudo_provider = ldap case_sensitive = False debug_level = 5 chpass_provider = ldap #pam_password = md5 #chpass_provider = krb5 cache_credentials = False ldap_user_name = uid ldap_default_authtok_type = password ldap_search_base = dc=companyname,dc=com ldap_user_search_base = ou=companynameAccts,DC=companyname,DC=com ldap_group_search_base = OU=companynameGroups,dc=companyname,dc=com ldap_default_bind_dn = uid=linuxuser,ou=companynameaccts,dc=companyname,dc=com ldap_uri = ldaps://ldapserver.eweprod.companyname.com ldap_sudo_search_base = ou=SUDOers,dc=companyname,dc=com ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = demand ldap_schema = rfc2307bis ldap_id_use_start_tls = False ldap_default_authtok = password access_provider = simple simple_allow_groups = tester1, tester2 use_host_filter = false #sudo ldap_sudo_full_refresh_interval=86400 ldap_sudo_smart_refresh_interval=3600 [sssd] config_file_version = 2 services = nss, pam, sudo domains = companyname debug_level = 5 [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] [sudo] debug_level = 6 = /etc/pam.d/sudo --- #%PAM-1.0 auth sufficientpam_ldap.so uth required pam_unix.so try_first_pass auth required pam_nologin.so auth include system-auth accountinclude system-auth password include system-auth sessionoptional pam_keyinit.so revoke sessionrequired pam_limits.so -- Output log: -- (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [username] from [ALL] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [username@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [username] from [companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=username)(sudoUser=#1000)(sudoUser=%group1)(sudoUser=+*))((dataExpireTimestamp=1402933038)))] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(name=defaults)))] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [default options@companyname] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Jun 16 11:37:18 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username (Mon Jun 16 11:37:18 2014) [sssd[sudo]]
Re: dnf v.s. yum
On 16. 6. 2014 at 07:19:45, Stephen Morris wrote: On 06/15/2014 11:23 PM, Ed Greshko wrote: On 06/15/14 19:02, Tim wrote: On Sun, 2014-06-15 at 18:27 +0800, Ed Greshko wrote: OK I read FAQ. http://akozumpl.github.io/dnf/user_faq.html#why-do-i-get-different-resul ts-with-dnf-update-vs-yum-update And the one following it Is it possible to force DNF to get the latest metadata on dnf upgrade? Running KDE and the notifications in the systray showed there are 12 updates available. Figured I give dnf a try, which I've done from time to time, but it showed no packages to update. OKso clean metadata for both yum and dnf ran both yum check-update and dnf check-update. yum listed the 12 And dnf offered nothing... Is this just a case of whatever generates the metadata that yum uses, and whatever else generates the metadata that dnf uses, do their generation at different times? Or do they actually have a different set of package files to look through? I can't help but wonder what changing from yum to dnf will do for mirror sites. Are we going to see a prolonged period where various mirrors stagnate? Right But, now it does I thought clean metadata would have done it But, clean expire-cache seems to have done the trick. Can Yum cache updates and DNF cache updates interfere with each other? Since installing DNF I randomly get out of space conditions on cache updates which I have queried in another thread. I don't understand why this occurs when the file I think it is trying to update is 25 GB in size and there is 695 GB free space in the partition where the cache is. Have you experienced this sort of thing, or should I be raising a bug report (the issue with a bug report is at the moment I'm not sure if it is DNF or Yum producing the error message, and, if it is Yum, given that DNF is replacing Yum in Fedora 22 is anybody going to care anyway?). Hi Steve, I'm not sure I understand your situation entirely but the short version is: yum cache and dnf cache are two separate things so they do not interfere with each other. May I ask what 25G file do you have on fs that needs updating? I have never seen rpms of such size and quite frankly I was under the impression that it wasn't even possible to build them using rpm until recently. Thanks Jan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/14 00:27, Rejy M Cyriac wrote: On 06/09/2014 06:00 PM, Matthew Miller wrote: On Mon, Jun 09, 2014 at 09:59:15AM +0200, Jan Zelený wrote: till October) will give folks plenty of time to hone their dnf skills. IMO, for many (majority?) it will be a drop-in replacement for yum. Yes, that's the plan. There are some differences but they are all well documented. Is the plan to actually rename dnf to yum at that point? If it is truly a drop-in replacement, that seems like the less disruptive approach for users (and scripts) everywhere. Additionally, in remembrance of Seth Vidal, I would hate to see Fedora lose 'yum'. Even if Seth would probably find that silly, it's important to me. +1 Let us keep at least the name, if not the code. I have been a happy user of yum, and have observed it to be innovative enough. By the way, 'dnf erase kernel' scares me :-O [root@box10 bobg]# dnf update Dependencies resolved. Nothing to do. and then: [root@box10 bobg]# yum update Loaded plugins: ... snip ,,, Dependencies Resolved = Package Arch Version RepositorySize = Updating: NetworkManager x86_64 1:0.9.9.0-39.git20131003.fc20 updates 1.2 M NetworkManager-glib x86_64 1:0.9.9.0-39.git20131003.fc20 updates 348 k ghostscript x86_64 9.14-3.fc20 updates 4.4 M gnome-abrt x86_64 0.3.7-1.fc20 updates 213 k qt x86_64 1:4.8.6-9.fc20 updates 4.7 M qt-x11 x86_64 1:4.8.6-9.fc20 updates 13 M thunderbird x86_64 24.6.0-1.fc20 updates 45 M yumexnoarch 3.0.15-1.fc20 updates 431 k Transaction Summary = Upgrade 8 Packages Total download size: 68 M Is this ok [y/d/N]: y So there is still a considerable difference in what each of them does here, Bob -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/14 16:37, Bob Goodwin - Zuni, Virginia, USA wrote: So there is still a considerable difference in what each of them does here, I ran into this the other day. It would seem the way dnf handles caching is different from yum. Not 100% sure/convinced this fixed my problembut after running dnf clean expire-cache it then reported the same thing as yum. -- Do not condemn the judgment of another because it differs from your own. You may both be wrong. -- Dandemis -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Firefox 30 and NTLM auth
After last firefox update the NTLM auth do not work anymore. I have download the previous version of FF from Fedora old repo (firefox-29.0.1-1.fc20.x86_64.rpm) and install it: NTLM auth work. (NOTE: yum downgrade firefox do not work with this error) Resolving Dependencies -- Running transaction check --- Package firefox.x86_64 0:25.0-3.fc20 will be a downgrade -- Processing Dependency: libxul.so(xul25.0)(64bit) for package: firefox-25.0-3.fc20.x86_64 --- Package firefox.x86_64 0:30.0-4.fc20 will be erased -- Processing Conflict: firefox-25.0-3.fc20.x86_64 conflicts xulrunner(x86-64) 25.1 -- Finished Dependency Resolution Error: firefox conflicts with xulrunner-30.0-1.fc20.x86_64 I have also download FF from FF web site and the problem is the same: FF30 do not work, FF 29 work. Some suggest ? Thanks -- Dario Lesca (inviato dal mio Linux Fedora 20 con Gnome 3.10.4) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Firefox 30 and NTLM auth
On 06/16/14 17:15, Dario Lesca wrote: After last firefox update the NTLM auth do not work anymore. I have download the previous version of FF from Fedora old repo (firefox-29.0.1-1.fc20.x86_64.rpm) and install it: NTLM auth work. (NOTE: yum downgrade firefox do not work with this error) Resolving Dependencies -- Running transaction check --- Package firefox.x86_64 0:25.0-3.fc20 will be a downgrade -- Processing Dependency: libxul.so(xul25.0)(64bit) for package: firefox-25.0-3.fc20.x86_64 --- Package firefox.x86_64 0:30.0-4.fc20 will be erased -- Processing Conflict: firefox-25.0-3.fc20.x86_64 conflicts xulrunner(x86-64) 25.1 -- Finished Dependency Resolution Error: firefox conflicts with xulrunner-30.0-1.fc20.x86_64 I have also download FF from FF web site and the problem is the same: FF30 do not work, FF 29 work. Some suggest ? One thing you can try. In FF30 they seem to have added a new parameter network.negotiate-auth.allow-insecure-ntlm-v1 to about:config. By default it is set to false. Try setting it to true. -- Do not condemn the judgment of another because it differs from your own. You may both be wrong. -- Dandemis -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/14 04:42, Ed Greshko wrote: On 06/16/14 16:37, Bob Goodwin - Zuni, Virginia, USA wrote: So there is still a considerable difference in what each of them does here, I ran into this the other day. It would seem the way dnf handles caching is different from yum. Not 100% sure/convinced this fixed my problembut after running dnf clean expire-cache it then reported the same thing as yum. I will try that next time, thanks. Bob -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Firefox 30 and NTLM auth
Il giorno lun, 16/06/2014 alle 17.54 +0800, Ed Greshko ha scritto: One thing you can try. In FF30 they seem to have added a new parameter network.negotiate-auth.allow-insecure-ntlm-v1 to about:config. By default it is set to false. Try setting it to true. I love this kind of suggest because it solve the problem. With this setting to true, the NTLM of FF30 work again Many Thanks -- Do not condemn the judgment of another because it differs from your own. You may both be wrong. -- Dandemis -- Dario Lesca (inviato dal mio Linux Fedora 20 con Gnome 3.10.4) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 14. 6. 2014 at 11:05:03, Stephen Morris wrote: On 06/14/2014 12:05 AM, Aleksandar Kostadinov wrote: Tom Horsley wrote, On 06/07/2014 03:57 PM (EEST): On Sat, 7 Jun 2014 07:47:37 -0500 Bruno Wolff III wrote: For one thing the depsolving algorithm used by yum is slow. Not so an ordinary human could notice it compared (for example) to the time it takes to rebuild the rpms from the deltas. Not everybody is runnig fedora on a 2GB+ machine. I welcome the move to more efficient package management. Especially if it is mostly backward compatible. Most users shouldn't notice. I've just installed python3-dnf and python3-dnf-plugins-core and when I run dnf I get the following messages: dnf --version Traceback (most recent call last): File /usr/bin/dnf, line 35, in module from dnf.cli import main ImportError: No module named dnf.cli If instead I install dnf and dnf-plugins-core, which are the python2.7 versions they run fine. I have manually also installed the python-cli packages which was not instead when installing either version of dnf. That sounds like a bug and if you used up-to-date version of dnf, you should definitely report it in bugzilla. Thanks Jan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 6/16/2014 1:05 AM, Ed Greshko wrote: On 06/16/14 12:27, Rejy M Cyriac wrote: By the way, 'dnf erase kernel' scares me :-O FWIW, it has been suggested that the DNF developers would consider this a bug if the number of CC's on https://bugzilla.redhat.com/show_bug.cgi?id=1049310 was over 40. It now stands at 40. But, it wouldn't hurt to have others add themselves to the list to increase the #. 43 now but it is marked CLOSED WONTFIX. So you think that they will change their mind? -- David -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/14 19:00, David wrote: On 6/16/2014 1:05 AM, Ed Greshko wrote: On 06/16/14 12:27, Rejy M Cyriac wrote: By the way, 'dnf erase kernel' scares me :-O FWIW, it has been suggested that the DNF developers would consider this a bug if the number of CC's on https://bugzilla.redhat.com/show_bug.cgi?id=1049310 was over 40. It now stands at 40. But, it wouldn't hurt to have others add themselves to the list to increase the #. 43 now but it is marked CLOSED WONTFIX. So you think that they will change their mind? Let's just put it this way They may or they may not, but adding to the cc list couldn't hurt. Who knows, it may take a large paid user of RHEL suffering an avoidable failure to convince them. -- Do not condemn the judgment of another because it differs from your own. You may both be wrong. -- Dandemis -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On Sun, 2014-06-15 at 21:12 +0200, Lars E. Pettersson wrote: On 06/09/14 16:28, Patrick O'Callaghan wrote: Do you have the bug reference? I'd rather find out before dnf leaves me with a non-bootable system. The reason I'm harping on about it is that in a thread on this list a few months back the developers didn't seem to think it was a bug. It has not been fixed. See bug 1049310. Ales wrote the following If there's enough CCs in this bug (40) I will consider the proper way to implement something that prevents 'dnf erase kernel' from removing the running kernel. So if you want that behaviour (the way yum does it), make a CC to that bug. Done. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 6/16/2014 7:19 AM, Ed Greshko wrote: On 06/16/14 19:00, David wrote: On 6/16/2014 1:05 AM, Ed Greshko wrote: On 06/16/14 12:27, Rejy M Cyriac wrote: By the way, 'dnf erase kernel' scares me :-O FWIW, it has been suggested that the DNF developers would consider this a bug if the number of CC's on https://bugzilla.redhat.com/show_bug.cgi?id=1049310 was over 40. It now stands at 40. But, it wouldn't hurt to have others add themselves to the list to increase the #. 43 now but it is marked CLOSED WONTFIX. So you think that they will change their mind? Let's just put it this way They may or they may not, but adding to the cc list couldn't hurt. Who knows, it may take a large paid user of RHEL suffering an avoidable failure to convince them. Perhaps. Have you any knowledge of a Bugzilla marked CLOSED WONTFIX being changed? As for a large paid user of RHEL having a problem. That could happen but I can also see the admin looking for work with a serious bad mark on his/her resume. :-) -- David -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Firefox 30 and NTLM auth
On 06/16/14 18:33, Dario Lesca wrote: I love this kind of suggest because it solve the problem. With this setting to true, the NTLM of FF30 work again Many Thanks You're welcome. This setting does seem to indicate that if you have control over the other system you should update it to run v2 which is considered more secure. -- Do not condemn the judgment of another because it differs from your own. You may both be wrong. -- Dandemis -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 16. 6. 2014 at 07:49:55, David wrote: On 6/16/2014 7:19 AM, Ed Greshko wrote: On 06/16/14 19:00, David wrote: On 6/16/2014 1:05 AM, Ed Greshko wrote: On 06/16/14 12:27, Rejy M Cyriac wrote: By the way, 'dnf erase kernel' scares me :-O FWIW, it has been suggested that the DNF developers would consider this a bug if the number of CC's on https://bugzilla.redhat.com/show_bug.cgi?id=1049310 was over 40. It now stands at 40. But, it wouldn't hurt to have others add themselves to the list to increase the #. 43 now but it is marked CLOSED WONTFIX. So you think that they will change their mind? Let's just put it this way They may or they may not, but adding to the cc list couldn't hurt. Who knows, it may take a large paid user of RHEL suffering an avoidable failure to convince them. Perhaps. Have you any knowledge of a Bugzilla marked CLOSED WONTFIX being changed? We originally didn't want to implement anything like this for three reasons: a) in our opinion, dnf should not do the thinking for admins b) the real impact of this feature is questionable c) we don't want dnf to contain ugly hacks from the beginning ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. That being said, if users accidentally instruct yum to erase the running kernel on a regular basis, we are will reconsider this argument. Hence the poll ... feel free to reopen the bug too, otherwise it might get off the radar. ad c) if we are to implement this, it will be a part of systematic solution, no workarounds or hackish constructs in the code base. It might take a while longer but the difference will be worth the effort, I'm sure. Thanks Jan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
Hi On Mon, Jun 16, 2014 at 8:45 AM, Jan Zelený wrote: ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. You are assuming limited by your own experience that this is done accidentally. On the contrary, because of yum's behavior, its perfectly fine to quickly do a yum remove kernel to get rid of older kernels and retain the current one. I do this from time to time if I have to play around with third party kernel modules and don't want the other kernels interfering with that process. The protected packages feature in general is also useful not because anyone would do yum remove glibc directly but because other scripts that remove duplicate packages have been known to have bugs in the past which removed the critical packages instead and the protected packages feature would prevent such bugs from causing irrecoverable damage. Rahul -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On Mon, Jun 16, 2014 at 14:45:17 +0200, Jan Zelený jzel...@redhat.com wrote: ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. That being said, if users accidentally instruct yum to erase the running kernel on a regular basis, we are will reconsider this argument. Hence the poll ... feel free to reopen the bug too, otherwise it might get off the radar. Note that even updates can bite you if dnf will always be removing the oldest kernel, even if that is the one you are running. There may be kernel or dracut problems keeping the newer installed kernels from being usable on a particular system. Also if the running kernel is removed, you won't be able to load any modules that are already loaded. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
RE: Save everybody some surprises in Fedora 22!
On 06/16/14 04:42, Ed Greshko wrote: On 06/16/14 16:37, Bob Goodwin - Zuni, Virginia, USA wrote: So there is still a considerable difference in what each of them does here, I ran into this the other day. It would seem the way dnf handles caching is different from yum. Not 100% sure/convinced this fixed my problembut after running dnf clean expire-cache it then reported the same thing as yum. I will try that next time, thanks. Bob Dnf defaults to 48h metadata expiry. Yum default is much shorter (I found a reference saying it is 1.5h, but don't know if this is still true). You can set metadata_expire in /etc/dnf/dnf.conf - I dropped it to 6h. NOTICE DISCLAIMER This email including attachments (this Document) is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document. The information contained in this Document is provided solely for information purposes on an as is basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk. Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees, agents or representatives outside the scope of our business. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/2014 03:23 PM, Paul Knox-Kennedy wrote: On 06/16/14 04:42, Ed Greshko wrote: On 06/16/14 16:37, Bob Goodwin - Zuni, Virginia, USA wrote: So there is still a considerable difference in what each of them does here, I ran into this the other day. It would seem the way dnf handles caching is different from yum. Not 100% sure/convinced this fixed my problembut after running dnf clean expire-cache it then reported the same thing as yum. I will try that next time, thanks. Bob Dnf defaults to 48h metadata expiry. Yum default is much shorter (I found a reference saying it is 1.5h, but don't know if this is still true). You can set metadata_expire in /etc/dnf/dnf.conf - I dropped it to 6h. /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=100 best=1 deltarpm=1 debuglevel=10 errorlevel=10 metadata_expire=0 metadata_timer_sync=0 Regardless, its output is still ugly compared to yum daisies. Long live the yum! poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 16. 6. 2014 at 09:19:21, Rahul Sundaram wrote: Hi On Mon, Jun 16, 2014 at 8:45 AM, Jan Zelený wrote: ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. You are assuming limited by your own experience that this is done accidentally. And hence the poll Thanks Jan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/2014 04:04 PM, Jan Zelený wrote: On 16. 6. 2014 at 09:19:21, Rahul Sundaram wrote: Hi On Mon, Jun 16, 2014 at 8:45 AM, Jan Zelený wrote: ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. You are assuming limited by your own experience that this is done accidentally. And hence the poll Thanks Jan 80!? :) poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Error while updating system
I ran sudo yum update -y a few days ago, as I often do, and I saw the following error: Error: Package: kmod-VirtualBox-3.14.6-200.fc20.x86_64-4.3.12-1.fc20.2.x86_64 (rpmfusion-free-updates) Requires: kernel-uname-r = 3.14.6-200.fc20.x86_64 Installed: kernel-3.14.4-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.4-200.fc20.x86_64 Installed: kernel-3.14.5-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.5-200.fc20.x86_64 Installed: kernel-3.14.7-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.7-200.fc20.x86_64 Available: kernel-3.11.10-301.fc20.x86_64 (fedora) kernel-uname-r = 3.11.10-301.fc20.x86_64 Available: kernel-debug-3.11.10-301.fc20.x86_64 (fedora) kernel-uname-r = 3.11.10-301.fc20.x86_64+debug Available: kernel-debug-3.14.7-200.fc20.x86_64 (updates) kernel-uname-r = 3.14.7-200.fc20.x86_64+debug You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest So I ran sudo yum update -y --skip-broken, as suggested, and the update completed without incident. Then I left my machine alone for a few days, and came back to it figuring that I should run another update, so I did, and I received the same error. Does this indicate that anything worrisome is wrong? And, regardless, is there anything I could do to rectify the issue so that I don't keep having to run yum update commands with the --skip-broken option? Thanks -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Error while updating system
On Mon, 16 Jun 2014 22:36:02 +0800, Someone wrote: I ran sudo yum update -y a few days ago, as I often do, and I saw the following error: Error: Package: kmod-VirtualBox-3.14.6-200.fc20.x86_64-4.3.12-1.fc20.2.x86_64 (rpmfusion-free-updates) Requires: kernel-uname-r = 3.14.6-200.fc20.x86_64 Installed: kernel-3.14.4-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.4-200.fc20.x86_64 Installed: kernel-3.14.5-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.5-200.fc20.x86_64 Installed: kernel-3.14.7-200.fc20.x86_64 (@updates) kernel-uname-r = 3.14.7-200.fc20.x86_64 Available: kernel-3.11.10-301.fc20.x86_64 (fedora) kernel-uname-r = 3.11.10-301.fc20.x86_64 Available: kernel-debug-3.11.10-301.fc20.x86_64 (fedora) kernel-uname-r = 3.11.10-301.fc20.x86_64+debug Available: kernel-debug-3.14.7-200.fc20.x86_64 (updates) kernel-uname-r = 3.14.7-200.fc20.x86_64+debug You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest So I ran sudo yum update -y --skip-broken, as suggested, and the update completed without incident. Then I left my machine alone for a few days, and came back to it figuring that I should run another update, so I did, and I received the same error. Does this indicate that anything worrisome is wrong? You cannot let Yum remove old kernel packages from your installation, if a package like kmod-VirtualBox still requires that kernel. And, regardless, is there anything I could do to rectify the issue so that I don't keep having to run yum update commands with the --skip-broken option? Once you've booted with a newer kernel, you could uninstall older kernel packages *and* any kmod packages for those kernels. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Error while updating system
On 06/16/2014 11:25 PM, Michael Schwendt wrote: Once you've booted with a newer kernel, you could uninstall older kernel packages *and* any kmod packages for those kernels. What would that look like, in my case? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On Mon, Jun 16, 2014 at 04:04:24PM +0200, Jan Zelený wrote: You are assuming limited by your own experience that this is done accidentally. And hence the poll I'm a little skeptical that the poll will reach the right segment of responders to get a valuable response. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Firefox 30 and NTLM auth
Il giorno lun, 16/06/2014 alle 20.39 +0800, Ed Greshko ha scritto: You're welcome. This setting does seem to indicate that if you have control over the other system you should update it to run v2 which is considered more secure. The server to which I connect and use the NTLM V1 is a MS Intranet web server, and I do not have control on it, I'm a simple user only. I do not know how to migrate to v2 protocol. Thanks -- Dario Lesca (inviato dal mio Linux Fedora 20 con Gnome 3.10.4) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Firefox 30 and NTLM auth
*Security* *NTLMv1 auth has been disabled, NTLM support on non-Windows platforms is now deprecated* - Bug 828183 ? Firefox enables insecure NTLM (pre-NTLMv2) authentication https://bugzilla.mozilla.org/show_bug.cgi?id=828183 - Bug 999306 ? Allow generic NTLM v1 if pref set https://bugzilla.mozilla.org/show_bug.cgi?id=999306 - Bug 1023748 ? Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non-Windows platforms https://bugzilla.mozilla.org/show_bug.cgi?id=1023748 The support for the NT LAN Manager version 1 (NTLMv1) network authentication has been disabled because it's known as insecure. Companies and organizations still deploying the older protocol should upgrade to NTLMv2. See Honza Bambas' blog post http://www.janbambas.cz/ntlm-v1-and-firefox/ and Jason Duell's post to the dev-planning list https://groups.google.com/d/topic/mozilla.dev.planning/JbrpDmqDLXI for details. This is affecting SharePoint-based or IIS-backed intranet applications. If you encounter any problems on Firefox 30 or later, you can manually enable NTLMv1 using a preference. Note that NTLMv2 is not supported on non-Windows platforms, so OS X and Linux users have to toggle the preference to continue using NTLMv1 as below, though the NTLM auth support on non-Windows platforms is considered deprecate d. How to enable NTLMv1: type about:config in the location bar, click the I'll be careful button, find network.negotiate-auth.allow-insecure-ntlm-v1, double-click on it to change the value to true. You can check to see if NTLMv2 is enabled using the following: https://www.imss.caltech.edu/node/395 On Mon, Jun 16, 2014 at 9:15 AM, Dario Lesca d.le...@solinos.it wrote: After last firefox update the NTLM auth do not work anymore. I have download the previous version of FF from Fedora old repo (firefox-29.0.1-1.fc20.x86_64.rpm) and install it: NTLM auth work. (NOTE: yum downgrade firefox do not work with this error) Resolving Dependencies -- Running transaction check --- Package firefox.x86_64 0:25.0-3.fc20 will be a downgrade -- Processing Dependency: libxul.so(xul25.0)(64bit) for package: firefox-25.0-3.fc20.x86_64 --- Package firefox.x86_64 0:30.0-4.fc20 will be erased -- Processing Conflict: firefox-25.0-3.fc20.x86_64 conflicts xulrunner(x86-64) 25.1 -- Finished Dependency Resolution Error: firefox conflicts with xulrunner-30.0-1.fc20.x86_64 I have also download FF from FF web site and the problem is the same: FF30 do not work, FF 29 work. Some suggest ? Thanks -- Dario Lesca (inviato dal mio Linux Fedora 20 con Gnome 3.10.4) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Wifi connection issues with Intel?
On 06/12/2014 10:14 AM, Richard Shaw wrote: On Thu, Jun 12, 2014 at 6:56 AM, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: The full unifi software is java with a mongodb database backend and works fine. I have a RPM I created, the only problem I haven't been able to fix is the selinux issues, one for the private mongodb instance, and then the ports it binds to. Please open a bugzilla for the SELinux issues. Before I open a BZ, here's what I have in my spec file which from what I understand should be persistent... %posttrans /usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/logs(/.*)? /usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data(/.*)? /usr/sbin/semanage port -m -t mongod_port_t 27117 Or should this be handled in a policy? Thanks, Richard I think your post install should look like. /usr/sbin/semanage fcontext -e /var/log/mongod /var/lib/unifi/logs /usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data /usr/sbin/semanage port -m -t mongod_port_t 27117 Don't use the regex. Also I would figure the logs should be labeled mongod_log_t rather then mongod_lib_t. If this is a standard location for this code, we should put it into the base package. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Wifi connection issues with Intel?
On Mon, Jun 16, 2014 at 12:19 PM, Daniel J Walsh dwa...@redhat.com wrote:
On 06/12/2014 10:14 AM, Richard Shaw wrote:
On Thu, Jun 12, 2014 at 6:56 AM, Daniel J Walsh dwa...@redhat.com
wrote:
The full unifi software is java with a mongodb database backend and
works fine. I have a RPM I created, the only problem I haven't been able to
fix is the selinux issues, one for the private mongodb instance, and then
the ports it binds to.
Please open a bugzilla for the SELinux issues.
Before I open a BZ, here's what I have in my spec file which from what I
understand should be persistent...
%posttrans
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/logs(/.*)?
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data(/.*)?
/usr/sbin/semanage port -m -t mongod_port_t 27117
Or should this be handled in a policy?
Thanks,
Richard
I think your post install should look like.
/usr/sbin/semanage fcontext -e /var/log/mongod /var/lib/unifi/logs
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data
/usr/sbin/semanage port -m -t mongod_port_t 27117
Don't use the regex. Also I would figure the logs should be labeled
mongod_log_t rather then mongod_lib_t.
What is the concern with regex? It is specific to packaging? Most of the
examples I found online used that method... As far as the label, since
everything is getting dumped in /var/lib I figured that would be OK.
If this is a standard location for this code, we should put it into the
base package.
There is not a standard install location, the install will work as long
as everything stays in the same relative location (the unifi directory).
Since it writes a lot of stuff I figured /var was the best (only?) real
option.
Following the example of a draft wiki I can't find anymore I had modified
the scripts to this instead of using %posttrans:
%post
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
restorecon -R %{_sharedstatedir}/unifi/logs || :
restorecon -R %{_sharedstatedir}/unifi/data || :
semanage port -m -t mongod_port_t 27117 || :
%postun
if [ $1 -eq 0 ] ; then # final removal
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
fi
Thanks,
Richard
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Wifi connection issues with Intel?
On 06/16/2014 01:35 PM, Richard Shaw wrote:
On Mon, Jun 16, 2014 at 12:19 PM, Daniel J Walsh dwa...@redhat.com
mailto:dwa...@redhat.com wrote:
On 06/12/2014 10:14 AM, Richard Shaw wrote:
On Thu, Jun 12, 2014 at 6:56 AM, Daniel J Walsh
dwa...@redhat.com mailto:dwa...@redhat.com wrote:
The full unifi software is java with a mongodb database
backend and works fine. I have a RPM I created, the only
problem I haven't been able to fix is the selinux issues,
one for the private mongodb instance, and then the ports it
binds to.
Please open a bugzilla for the SELinux issues.
Before I open a BZ, here's what I have in my spec file which from
what I understand should be persistent...
%posttrans
/usr/sbin/semanage fcontext -e /var/lib/mongod
/var/lib/unifi/logs(/.*)?
/usr/sbin/semanage fcontext -e /var/lib/mongod
/var/lib/unifi/data(/.*)?
/usr/sbin/semanage port -m -t mongod_port_t 27117
Or should this be handled in a policy?
Thanks,
Richard
I think your post install should look like.
/usr/sbin/semanage fcontext -e /var/log/mongod /var/lib/unifi/logs
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data
/usr/sbin/semanage port -m -t mongod_port_t 27117
Don't use the regex. Also I would figure the logs should be
labeled mongod_log_t rather then mongod_lib_t.
What is the concern with regex?
It is specific to packaging? Most of the examples I found online used
that method... As far as the label, since everything is getting dumped
in /var/lib I figured that would be OK.
Not a concern with regex. it just will not work. The examples you have
seen on line, were not using equivalence. They were using generic
labelling.
Equivalence tells SELinux to swap the second part of the path with the
first. You code would only match file paths that began with
/var/lib/unifi/logs(/.*?) Not /var/lib/unifi/logs/foobar.log
If this is a standard location for this code, we should put it
into the base package.
There is not a standard install location, the install will work as
long as everything stays in the same relative location (the unifi
directory). Since it writes a lot of stuff I figured /var was the best
(only?) real option.
Yes
Following the example of a draft wiki I can't find anymore I had
modified the scripts to this instead of using %posttrans:
%post
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
restorecon -R %{_sharedstatedir}/unifi/logs || :
restorecon -R %{_sharedstatedir}/unifi/data || :
semanage port -m -t mongod_port_t 27117 || :
%postun
if [ $1 -eq 0 ] ; then # final removal
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
fi
Thanks,
Richard
That should work. You could speed it up by combining both semange
fcontext lines into a single transaction. Something like.
semanage -S targeted -i - _EOF
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/logs(/.*)?
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/data(/.*)?
_EOF 2/dev/null || :
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Selinux Packaging [WAS: Wifi connection issues with Intel?]
On Mon, Jun 16, 2014 at 1:08 PM, Daniel J Walsh dwa...@redhat.com wrote:
On 06/16/2014 01:35 PM, Richard Shaw wrote:
On Mon, Jun 16, 2014 at 12:19 PM, Daniel J Walsh dwa...@redhat.com
wrote:
On 06/12/2014 10:14 AM, Richard Shaw wrote:
On Thu, Jun 12, 2014 at 6:56 AM, Daniel J Walsh dwa...@redhat.com
wrote:
The full unifi software is java with a mongodb database backend and
works fine. I have a RPM I created, the only problem I haven't been able to
fix is the selinux issues, one for the private mongodb instance, and then
the ports it binds to.
Please open a bugzilla for the SELinux issues.
Before I open a BZ, here's what I have in my spec file which from what
I understand should be persistent...
%posttrans
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/logs(/.*)?
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data(/.*)?
/usr/sbin/semanage port -m -t mongod_port_t 27117
Or should this be handled in a policy?
Thanks,
Richard
I think your post install should look like.
/usr/sbin/semanage fcontext -e /var/log/mongod /var/lib/unifi/logs
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data
/usr/sbin/semanage port -m -t mongod_port_t 27117
Don't use the regex. Also I would figure the logs should be labeled
mongod_log_t rather then mongod_lib_t.
What is the concern with regex?
It is specific to packaging? Most of the examples I found online used
that method... As far as the label, since everything is getting dumped in
/var/lib I figured that would be OK.
Not a concern with regex. it just will not work. The examples you have
seen on line, were not using equivalence. They were using generic
labelling.
Equivalence tells SELinux to swap the second part of the path with the
first. You code would only match file paths that began with
/var/lib/unifi/logs(/.*?) Not /var/lib/unifi/logs/foobar.log
If this is a standard location for this code, we should put it into the
base package.
There is not a standard install location, the install will work as
long as everything stays in the same relative location (the unifi
directory). Since it writes a lot of stuff I figured /var was the best
(only?) real option.
Yes
Following the example of a draft wiki I can't find anymore I had
modified the scripts to this instead of using %posttrans:
%post
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
restorecon -R %{_sharedstatedir}/unifi/logs || :
restorecon -R %{_sharedstatedir}/unifi/data || :
semanage port -m -t mongod_port_t 27117 || :
%postun
if [ $1 -eq 0 ] ; then # final removal
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
fi
That should work. You could speed it up by combining both semange
fcontext lines into a single transaction. Something like.
semanage -S targeted -i - _EOF
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/logs(/.*)?
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/data(/.*)?
_EOF 2/dev/null || :
Ok, just to be clear, I still need to remove the (/.*)? parts? I found the
packaging draft I referred to:
http://fedoraproject.org/wiki/PackagingDrafts/SELinux
Which shows including it.
Thanks,
Richard
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
problems with a high res display
I have a Dell M4800 with a 3200x1800 display, an nVidia Quadro 2100M, and Fedora 20. It was working very well. But after installing updates today, the gnome display manager cannot start. Anyone know of a fix? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Selinux Packaging [WAS: Wifi connection issues with Intel?]
On 06/16/2014 02:15 PM, Richard Shaw wrote:
On Mon, Jun 16, 2014 at 1:08 PM, Daniel J Walsh dwa...@redhat.com
mailto:dwa...@redhat.com wrote:
On 06/16/2014 01:35 PM, Richard Shaw wrote:
On Mon, Jun 16, 2014 at 12:19 PM, Daniel J Walsh
dwa...@redhat.com mailto:dwa...@redhat.com wrote:
On 06/12/2014 10:14 AM, Richard Shaw wrote:
On Thu, Jun 12, 2014 at 6:56 AM, Daniel J Walsh
dwa...@redhat.com mailto:dwa...@redhat.com wrote:
The full unifi software is java with a mongodb database
backend and works fine. I have a RPM I created, the
only problem I haven't been able to fix is the selinux
issues, one for the private mongodb instance, and then
the ports it binds to.
Please open a bugzilla for the SELinux issues.
Before I open a BZ, here's what I have in my spec file which
from what I understand should be persistent...
%posttrans
/usr/sbin/semanage fcontext -e /var/lib/mongod
/var/lib/unifi/logs(/.*)?
/usr/sbin/semanage fcontext -e /var/lib/mongod
/var/lib/unifi/data(/.*)?
/usr/sbin/semanage port -m -t mongod_port_t 27117
Or should this be handled in a policy?
Thanks,
Richard
I think your post install should look like.
/usr/sbin/semanage fcontext -e /var/log/mongod
/var/lib/unifi/logs
/usr/sbin/semanage fcontext -e /var/lib/mongod
/var/lib/unifi/data
/usr/sbin/semanage port -m -t mongod_port_t 27117
Don't use the regex. Also I would figure the logs should be
labeled mongod_log_t rather then mongod_lib_t.
What is the concern with regex?
It is specific to packaging? Most of the examples I found online
used that method... As far as the label, since everything is
getting dumped in /var/lib I figured that would be OK.
Not a concern with regex. it just will not work. The examples you
have seen on line, were not using equivalence. They were using
generic labelling.
Equivalence tells SELinux to swap the second part of the path with
the first. You code would only match file paths that began with
/var/lib/unifi/logs(/.*?) Not /var/lib/unifi/logs/foobar.log
If this is a standard location for this code, we should put
it into the base package.
There is not a standard install location, the install will work
as long as everything stays in the same relative location (the
unifi directory). Since it writes a lot of stuff I figured /var
was the best (only?) real option.
Yes
Following the example of a draft wiki I can't find anymore I had
modified the scripts to this instead of using %posttrans:
%post
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -a -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
restorecon -R %{_sharedstatedir}/unifi/logs || :
restorecon -R %{_sharedstatedir}/unifi/data || :
semanage port -m -t mongod_port_t 27117 || :
%postun
if [ $1 -eq 0 ] ; then # final removal
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
fi
That should work. You could speed it up by combining both semange
fcontext lines into a single transaction. Something like.
semanage -S targeted -i - _EOF
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/logs(/.*)?
fcontext -a -t mongod_var_lib_t %{_sharedstatedir}/unifi/data(/.*)?
_EOF 2/dev/null || :
Ok, just to be clear, I still need to remove the (/.*)? parts? I found
the packaging draft I referred to:
http://fedoraproject.org/wiki/PackagingDrafts/SELinux
Which shows including it.
Thanks,
Richard
If you use -e option, you do not use them, if you are using -a
option you do.
Your first message said you used
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/logs(/.*)?
/usr/sbin/semanage fcontext -e /var/lib/mongod /var/lib/unifi/data(/.*)?
Which is wrong because you used the -e
Your second email said you were doing.
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/logs(/.*)? 2/dev/null || :
semanage fcontext -d -t mongod_var_lib_t \
%{_sharedstatedir}/unifi/data(/.*)? 2/dev/null || :
Which used the -a which was correct, it needs the regex.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away:
Re: Selinux Packaging [WAS: Wifi connection issues with Intel?]
On Mon, Jun 16, 2014 at 1:34 PM, Daniel J Walsh dwa...@redhat.com wrote: On 06/16/2014 02:15 PM, Richard Shaw wrote: Ok, just to be clear, I still need to remove the (/.*)? parts? I found the packaging draft I referred to: http://fedoraproject.org/wiki/PackagingDrafts/SELinux Which shows including it. Thanks, Richard If you use -e option, you do not use them, if you are using -a option you do. Ahh! Thank you, that's what I was missing. Thanks, Richard -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/14 14:45, Jan Zelený wrote: We originally didn't want to implement anything like this for three reasons: a) in our opinion, dnf should not do the thinking for admins It should have sensible defaults so that a user can not hose the system by accident. What would the use case be to remove the running kernel? If no use case exist, then why have that option exposed to the user? b) the real impact of this feature is questionable Try 'dnf remove kernel' and see what happens. Then try to fix the problem. c) we don't want dnf to contain ugly hacks from the beginning I do not regard sensible defaults as a hack. ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. Well, with 'yum erase kernel' you can not accidentally remove the running kernel, so what is your point? :) feel free to reopen the bug too, otherwise it might get off the radar. How do I, as a normal user, re-open a bug? Can not see any way more than cloning it. Is that how it's supposed to be done? (Google gave no conclusive answer) Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 16.06.2014 22:02, Lars E. Pettersson wrote: On 06/16/14 14:45, Jan Zelený wrote: ... ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. Well, with 'yum erase kernel' you can not accidentally remove the running kernel, so what is your point? :) Checkmate! :) poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On 06/16/2014 05:45 AM, Jan Zelený wrote: ad b) how many times have this feature actually saved you from erasing the kernel? I can remember needing to get rid of all kernels except for the running one on at least one occasion. (It was the oldest one and for some reason the two newer ones weren't working.) Simply using yum erase kernel did the trick because it ignored the one in use. Yes, I could have done it by specifying the exact names, but this was much simpler. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On Mon, Jun 16, 2014 at 02:45:17PM +0200, Jan Zelený wrote: ad b) how many times have this feature actually saved you from erasing the kernel? In 10+ years using Linux I have never managed to do this accidentally. That being said, if users accidentally instruct yum to erase the running kernel on a regular basis, we are will reconsider this argument. Hence the poll ... feel free to reopen the bug too, otherwise it might get off the radar. I don't know about the kernel option in specific, but the _general_ package protection option (initially a plugin, and then integrated into the core as it proved to be generally useful) has saved me many times, and probably more importantly, I'm sure it's saved me saved me on support for systems where the user has root access and or where students admin the machines. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
On Mon, Jun 16, 2014 at 10:02:52PM +0200, Lars E. Pettersson wrote: On 06/16/14 14:45, Jan Zelený wrote: feel free to reopen the bug too, otherwise it might get off the radar. How do I, as a normal user, re-open a bug? Can not see any way more than cloning it. Is that how it's supposed to be done? (Google gave no conclusive answer) To do this, switch the bug state back to ASSIGNED. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
