Re: [CentOS] [OT] Where to buy S/MIME ??
On 11/28/2018 07:58 PM, Gordon Messmer wrote: On 11/27/18 3:47 PM, Alice Wonder wrote: I actually went for a more complex scenario, I've created my own CA complete with CRL. OK. That means fewer certificates for your peers to install over time, but is otherwise no better than self-signed. It's nice because with S/MIME you really want two certs - one for signing (where ecdsa can be used) and one for when you need to receive encrypted. IIRC, an S/MIME client should be able to install your public cert and encrypt messages sent to you with no user interaction. With Thunderbird, if I reply to a signed message, I can encrypt the reply. From a usability standpoint, I really want to have just one certificate. The easier it is to send me encrypted messages, the more likely it is that messages will be secure. A) For one certificate to do both it has to be an RSA cert but the primary use of S/MIME is signing where RSA is excessively bloated compared to ECDSA. B) Certs for encryption have to have a backup key somewhere so there isn't data loss if I lose the private key, and that key needs to be w/o a pass phrase in case something happens to me and someone else needs access to the encrypted messages. But having such a backup means it isn't safe to use for digital signing because the backup is a theft risk, so signing with that key to prove it is me isn't a great idea. Web browsers are applications that exist for the explicit purpose of downloading and executing untrusted code. It does not seem like that is a very wise environment to use for generating long term cryptography keys. It really doesn't. On the other hand, if you don't trust your browser's cryptography implementation, you definitely should not be using your browser for secure communication (https). https is handled by a TLS library outside the browser, which is vastly different than in browser generation of private keys. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] Where to buy S/MIME ??
On 11/27/18 3:47 PM, Alice Wonder wrote: I actually went for a more complex scenario, I've created my own CA complete with CRL. OK. That means fewer certificates for your peers to install over time, but is otherwise no better than self-signed. It's nice because with S/MIME you really want two certs - one for signing (where ecdsa can be used) and one for when you need to receive encrypted. IIRC, an S/MIME client should be able to install your public cert and encrypt messages sent to you with no user interaction. With Thunderbird, if I reply to a signed message, I can encrypt the reply. From a usability standpoint, I really want to have just one certificate. The easier it is to send me encrypted messages, the more likely it is that messages will be secure. Web browsers are applications that exist for the explicit purpose of downloading and executing untrusted code. It does not seem like that is a very wise environment to use for generating long term cryptography keys. It really doesn't. On the other hand, if you don't trust your browser's cryptography implementation, you definitely should not be using your browser for secure communication (https). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Gnome_shell out of memory
Hi All, I have a CentOS 7.5 box running. Its crashing after some time with NO memory. I have 4G in the box, and 4G swap. Nov 28 07:43:20 mediacontroller01 kernel: gnome-shell cpuset=/ mems_allowed=0 Nov 28 07:43:20 mediacontroller01 kernel: CPU: 2 PID: 1419 Comm: gnome-shell Tainted: G OE 3.10.0-862.3.3.el7.x86_64 #1 Nov 28 07:43:20 mediacontroller01 kernel: 763965 total pagecache pages Nov 28 07:43:20 mediacontroller01 kernel: 792 pages in swap cache Nov 28 07:43:20 mediacontroller01 kernel: Swap cache stats: add 1762910, delete 1762118, find 15701/18190 Nov 28 07:43:20 mediacontroller01 kernel: Free swap = 0kB Nov 28 07:43:20 mediacontroller01 kernel: Total swap = 4095996kB Nov 28 07:43:20 mediacontroller01 kernel: 1020385 pages RAM Nov 28 07:43:20 mediacontroller01 kernel: 0 pages HighMem/MovableOnly Nov 28 07:43:20 mediacontroller01 kernel: 78196 pages reserved Nov 28 07:43:20 mediacontroller01 kernel: Out of memory: Kill process 1419 (gnome-shell) score 25 or sacrifice child Nov 28 07:43:20 mediacontroller01 kernel: Killed process 1419 (gnome-shell) total-vm:9632020kB, anon-rss:179608kB, file-rss:924kB, shmem-rss:4504kB Nov 28 07:43:20 mediacontroller01 gnome-session-binary[1332]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 9 Nov 28 07:43:20 mediacontroller01 gnome-session: gnome-session-binary[1332]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 9 Nov 28 07:43:22 mediacontroller01 journal: JS WARNING: [resource:///org/gnome/shell/ui/main.js 315]: reference to undefined property "MetaStage" Nov 28 07:43:22 mediacontroller01 journal: JS WARNING: [resource:///org/gnome/shell/ui/layout.js 221]: reference to undefined property "MetaWindowGroup" Nov 28 07:43:22 mediacontroller01 journal: JS WARNING: [resource:///org/gnome/shell/ui/osdMonitorLabeler.js 59]: reference to undefined property "MetaDBusDisplayConfigSkeleton" Nov 28 07:43:22 mediacontroller01 journal: Failed to launch ibus-daemon: Failed to execute child process “ibus-daemon” (No such file or directory) Nov 28 07:43:23 mediacontroller01 journal: JS WARNING: [resource:///org/gnome/shell/ui/slider.js 38]: reference to undefined property "CallyActor" Nov 28 07:43:23 mediacontroller01 dbus[817]: [system] Activating via systemd: service name='org.freedesktop.GeoClue2' unit='geoclue.service' Nov 28 07:43:23 mediacontroller01 systemd: Cannot add dependency job for unit firewalld.service, ignoring: Unit is masked. Nov 28 07:43:23 mediacontroller01 systemd: Starting Location Lookup Service... Nov 28 07:43:23 mediacontroller01 dbus[817]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service' Nov 28 07:43:23 mediacontroller01 dbus[817]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit not found. Nov 28 07:43:23 mediacontroller01 journal: Failed to connect to avahi service: Daemon not running Nov 28 07:43:23 mediacontroller01 dbus[817]: [system] Successfully activated service 'org.freedesktop.GeoClue2' Nov 28 07:43:23 mediacontroller01 systemd: Started Location Lookup Service. Nov 28 07:43:23 mediacontroller01 journal: No permission to trigger offline updates: Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.packagekit.trigger-offline-update is not registered Nov 28 07:43:23 mediacontroller01 org.gnome.Shell.desktop: Window manager warning: "XF86RFKill" is not a valid accelerator Nov 28 07:43:23 mediacontroller01 journal: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation Nov 28 07:43:24 mediacontroller01 gnome-shell: GNOME Shell started at Wed Nov 28 2018 07:43:23 GMT-0500 (EST) Nov 28 07:44:19 mediacontroller01 journal: failed to commit changes to dconf: The connection is closed I have not ran into that before - What does one do ? Thanks Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Tools/mechanisms for the management of access permissions in big filebased datasets
On Wed, 28 Nov 2018, Warren Young wrote:
Who here uses ACLs to good effect? Are you using more than just
getfacl/setfacl to do it?
We use NFSv4 ACLs on Lustre and Isilon filesystems, so we employ
nfs4_getfacl and nfs4_setfacl -- but all of our work is done on the
command line, not via a GUI and larger management tool.
Our best practice is to script up the ACLs so they can be reapplied in
case they get deleted or inappropriately changed. My current scripting
logic usually writes the desired ACLs to temp files and deploys them
in one swoop.
Take the following case:
owner: bob
read-write group: boblab
read-only group: alicelab
target directory: /srv/group/boblab
A skeleton version of the script would look something like this
# define directory-level ACL and write to temp file
cat <<__DIRACL__ > /tmp/diracl
A::OWNER@:rwaDdxtTnNcCoy
A::GROUP@:rwaDxtTnNcy
A::EVERYONE@:tncy
A:fdg:bob...@domain.com:RWX
A:fdg:alice...@domain.com:RX
__DIRACL__
# define file-level ACL and write to temp file
cat <<__FILEACL__ > /tmp/fileacl
A::OWNER@:rwaDdxtTnNcCoy
A::GROUP@:rwaDxtTnNcy
A::EVERYONE@:tncy
A:g:bob...@domain.com:RWX
A:g:alice...@domain.com:RX
__FILEACL__
# apply ownership, perms, and ACLs.
chown -R bob:boblab /srv/group/boblab
chmod -R ug+rw,o-rwx /srv/group/boblab
find /srv/group/boblab -type d \
-exec nfs4_setfacl -S /tmp/diracl {} \;
find /srv/group/boblab -type f \
-exec nfs4_setfacl -S /tmp/fileacl {} \;
Once the directory ACLs are applied, any new files created within
those directories should inherit the proper ACLs.
--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS Dojo at FOSDEM, February 1, 2019
The final schedule for the CentOS Dojo at FOSDEM is now live at https://wiki.centos.org/Newsletter and registration is open. We've got a whole day of content for you, covering technical topics, information about RHEL 8 (and what's coming in CentOS), and updates from our Special Interest Groups (SIGs). Registration is free, but we do need you to register, so that we can adequately plan. We'll see you in Brussels! If you're not going to be at FOSDEM, but are interested in hosting a Dojo in your home town, get in touch with us on the centos-promo mailing list - https://lists.centos.org/mailman/listinfo/centos-promo - with your proposal. -- Rich Bowen - rbo...@redhat.com @CentOSProject // @rbowen 859 351 9166 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] Re: CentOS 7 package not present in Red Hat EL 7 - qt-assistant
On 11/28/18 2:59 AM, Toralf Lund wrote: > On 28/11/18 01:24, Akemi Yagi wrote: >> On Tue, Nov 27, 2018 at 5:47 AM Toralf Lund wrote: >>> I'm using CentOS 7 for development of software that is sometimes used on >>> Red Hat Enterprise Linux 7. I conjunction with an update of one of the >>> applications, I asked some Red Hat users to install the Qt 4 Assistant >>> application via the qt-assistant package (which is used by a "help" >>> function in our software.) It seemed like there was no such package in >>> the Red Hat package set, however, and I also see no mention of it in >>> "package manifests" like >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_7_html_package-5Fmanifest_chap-2Dbase-2Dworkstation-2Dvariant=DwICAg=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4=_4_0150hjtOLtAJXVP5zsLejT24DPdjAliL_UNY3-sM=y1xWd0RO1A06XoaFYkAGvj7ud88YK9MLgZY83UDe8Po=. >>> >>> Yet I can install the package from the "base" repository on my CentOS >>> machine. >>> >>> Questions: Isn't CentOS base supposed to contain exactly the same >>> packages as Red Hat Enterprise, except in some special cases that relate >>> to distribution information, installation sources etc.? Does anyone know >>> what's going on with the specific package I mention above? >>> >>> - Toralf >> The qt-assistant package is available in RHEL-7: >> >> $ sudo yum list qt-assistant >> >> qt-assistant.x86_64 1:4.8.7-2.el7 rhel-7-server-optional-rpms > Right. I notice the word "optional" here - I guess this is where some of > the confusion comes from, as the Red Hat doc mentioned above does not > say anything about optional packages, it just mentions base and > "supplementary" channels. Evidently, optional rpms are not enabled on > the system mentioned earlier... > > Also, this must mean that CentOS "base" is not the same as Red Hat > "base". Right? > CentOS has no need for Workstation, Server, Client, Compute Node designations .. nor the need for optional branches. Those are all things that are in place to create a different price point (Server vs. Client vs. Workstation vs. Computer Node .. those cost different amounts and contain different package sets of various sizes, more stuff costs more). CentOS is Free .. CentOS therefore contains all of those things. The optional RPMs come with a different level of support .. CentOS has NO support .. so CentOS contains ALL optional RPMs. So, in short .. the file manifest for CentOS contains all the RPMs from rebuild the RHEL source code that is included in the Workstation, Server, Client, Compute Node designations .. including the optional channels. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] Re: CentOS 7 package not present in Red Hat EL 7 - qt-assistant
On Wed, Nov 28, 2018 at 1:00 AM Toralf Lund wrote: > > On 28/11/18 01:24, Akemi Yagi wrote: > > The qt-assistant package is available in RHEL-7: > > > > $ sudo yum list qt-assistant > > > > qt-assistant.x86_64 1:4.8.7-2.el7rhel-7-server-optional-rpms > Right. I notice the word "optional" here - I guess this is where some of > the confusion comes from, as the Red Hat doc mentioned above does not > say anything about optional packages, it just mentions base and > "supplementary" channels. Evidently, optional rpms are not enabled on > the system mentioned earlier... > > Also, this must mean that CentOS "base" is not the same as Red Hat > "base". Right? > > - Toralf Please note that there are multiple Red Hat subscriptions. Workstation is one of them. CentOS builds all the packages made publicly available through git.centos.org. Akemi ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Tools/mechanisms for the management of access permissions in big filebased datasets
On Nov 28, 2018, at 2:36 AM, Frank Thommen wrote: > > Our problem is more the management side. Effectively we are looking for a > tool that helps us manage these permissions I want ACLs to work. There’s a real problem to solve, which is that the old user:group rwx Unix permission system doesn’t let you express common wishes like “Angel & Bobby own this file, and groups Cookie and Danish can read and write it, and user Egbert can write it.” The problem is, ACLs are hidden by default with respect to “ls -l”, and when you do make them visible with getfacl, you now have a complex mental parsing problem to solve before you understand the meaning of the ACL. Add in ACL inheritance and you’ve got a real mess. Make a facility hidden and complex, and you pretty much guarantee that few will use that facility, and those who do will at times create messes they can’t properly understand. A security mechanism that’s most often underused, misapplied, or both is a bad system. FOSS is good at solving such problems, so the only way I can see that tools to solve this problem don’t exist is that few actually use ACLs, perhaps because of the reasons above. Who here uses ACLs to good effect? Are you using more than just getfacl/setfacl to do it? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] aarch64 boot up process/EFI
Hello, I am not sure if this is the correct place to ask, but I do not have anyone else to go to. I'm working on building our own custom aarch64 RHEL distribution and using CentOS SRPMs to rebuild necessary packages. I am also utilizing kickstart. At this point, my kickstart installs all packages (by using a local repository with newly rebuild packages), but in the end I get an error "failed to write boot loader configuration". I noticed that i have /boot/efi/EFI/redhat directory on my newly "installed" server, while centos server has /boot/efi/EFI/centos directory. According to efibootmgr it is trying to boot \EFI\centos\shimaa64.efi, which doesn't exist (EFI\redhat\shimaa64.efi does). Those files are created by shim rpms and they are a total mess. I don't even know where to start or what to look for. `efibootmgr -v` shows in the beginning of BootOrder Boot* CentOS: HD (1,GPT,...)/File(\EFI\centos\shimaa64.efi). Shim package has the following files/directories: $ rpm -qlp shim-aa64-12-1 /boot/efi/EFI/BOOT/BOOTAA64.EFI /boot/efi/EFI/BOOT/fbaa64.efi /boot/efi/EFI/redhat/BOOTAA64.CSV /boot/efi/EFI/redhat/mmaa64.efi /boot/efi/EFI/redhat/shim.efi /boot/efi/EFI/redhat/shimaa64-redhat.efi /boot/efi/EFI/redhat/shimaa64.efi I have been reading EFI documentation and I understand the concept (or rather I think I do), but not sure how to make it all work with shim RPMs and/or how to properly rebuild them. Would really appreciate any advice... Thank you! Asya ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Tools/mechanisms for the management of access permissions in big filebased datasets
Thank you. Basically our problem are not the ACLs or their support per se, but that we have to manage a huge number of individual ACLS (several hundred users in more than hundred projects) in multi-petabyte filesystem and still have to keep overview and control. Our problem is more the management side. Effectively we are looking for a tool that helps us manage these permissions and we would accept whatever permissions mechanism this tool uses (UGO/ACLs). Cheers frank On 11/27/2018 03:06 PM, Leroy Tennison wrote: Well, there are extended ACLs if they're available in CentOS, when I first worked with them (long ago) they were new (and on a different Distro). I hope support for them has improved. They allow multiple users/groups to be assigned permissions to a file/directory. The problem then was that chmod (and other programs) were not extended-ACL-aware and could over-ride extended ACLs. There was a mechanism to recover from the situation but what it basically came down to was eternal vigilance - the system administrators had to understand (and agree about) extended ACLs and be careful/diligent in applying them. There are hacks which could possibly help (rename chmod and replace it with a script warning about extended ACLs) but, in the final analysis, it's not a decision to be undertaken lightly (unless the situation has changed dramatically). Leroy Tennison Network Information/Cyber Security Specialist E: le...@datavoiceint.com 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here . If you prefer not to be contacted by Harris Operating Group please notify us . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. From: CentOS on behalf of Frank Thommen Sent: Tuesday, November 27, 2018 7:25 AM To: CentOS mailing list Subject: [EXTERNAL] [CentOS] Tools/mechanisms for the management of access permissions in big filebased datasets Hello, we are currently managing access permissions through classical user-group-others permissions on a multi-petabyte directory tree with partially very deep and broad directories. Projects are represented by directory trees and mapped through GIDs. Lately we had lots of "singular" permission request (one single user needs access to a single dataset but should not be able to see all other datasets belonging to the same project). We realized, that the UGO model doesn't scale and is becoming more and more unmanageable. Can you recommend tools/mechanisms/technologies to overcome the drawbacks of the UGO model? We are thinking about some purely ACL based mechanism (but are open to other ideas). All filesystems in question are mounted via NFSv4 and the clients are (almost) completely CentOS 7.x hsots. Ideally the tool would have some web UI and some kind of (REST)API which allows us to modify permissions from our inhouse data management application (which does /not/ manage permissions, just the structure of the data). Additionally it should be able to visualize/report permissions in directory. I wasn't very successful in googling possible candidates, hence the question to the list. Cheers frank ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] Re: CentOS 7 package not present in Red Hat EL 7 - qt-assistant
On 28/11/18 01:24, Akemi Yagi wrote: On Tue, Nov 27, 2018 at 5:47 AM Toralf Lund wrote: I'm using CentOS 7 for development of software that is sometimes used on Red Hat Enterprise Linux 7. I conjunction with an update of one of the applications, I asked some Red Hat users to install the Qt 4 Assistant application via the qt-assistant package (which is used by a "help" function in our software.) It seemed like there was no such package in the Red Hat package set, however, and I also see no mention of it in "package manifests" like https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_7_html_package-5Fmanifest_chap-2Dbase-2Dworkstation-2Dvariant=DwICAg=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4=_4_0150hjtOLtAJXVP5zsLejT24DPdjAliL_UNY3-sM=y1xWd0RO1A06XoaFYkAGvj7ud88YK9MLgZY83UDe8Po=. Yet I can install the package from the "base" repository on my CentOS machine. Questions: Isn't CentOS base supposed to contain exactly the same packages as Red Hat Enterprise, except in some special cases that relate to distribution information, installation sources etc.? Does anyone know what's going on with the specific package I mention above? - Toralf The qt-assistant package is available in RHEL-7: $ sudo yum list qt-assistant qt-assistant.x86_64 1:4.8.7-2.el7rhel-7-server-optional-rpms Right. I notice the word "optional" here - I guess this is where some of the confusion comes from, as the Red Hat doc mentioned above does not say anything about optional packages, it just mentions base and "supplementary" channels. Evidently, optional rpms are not enabled on the system mentioned earlier... Also, this must mean that CentOS "base" is not the same as Red Hat "base". Right? - Toralf Akemi ___ CentOS mailing list CentOS@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos=DwICAg=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4=_4_0150hjtOLtAJXVP5zsLejT24DPdjAliL_UNY3-sM=loL65Otm0GZ6vbT3ASgXI-faGNq-mqoBwyMTIYmwB8Q= ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
