Re: [CentOS] CentOS 7 package not present in Red Hat EL 7 - qt-assistant
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://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/package_manifest/chap-base-workstation-variant. > 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 Akemi ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] Where to buy S/MIME ??
On Wed, 28 Nov 2018 00:54:12 +0100 Rainer Duffner wrote: > It’s of course a free country haven't heard that for quite a while... d -- In modern fantasy (literary or governmental), killing people is the usual solution to the so-called war between good and evil. My books are not conceived in terms of such a war, and offer no simple answers to simplistic questions. - Ursula Le Guin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] Where to buy S/MIME ??
> Am 28.11.2018 um 00:47 schrieb Alice Wonder : > > On 11/27/2018 03:33 PM, Gordon Messmer wrote: >> On 11/25/18 5:35 AM, Alice Wonder wrote: >>> The "free for personal" S/MIME from Comodo didn't work. Browser said it did >>> but there was nothing to export for me to then import. I suspect it is >>> because I used private browser window, >> Probably, yes. I've used that service in the past without issue. >>> I really don't like the idea of a private key stored in browser anyway. And >>> it never asked for a password to encrypt the private key >> Setting a password will protect all of the certificates stored by Firefox. >> Select: Preferences -> Privacy and Security -> Security Devices (under >> Certificates) -> Software Security Device -> Change password >> Chrome may have a similar option, but I don't see it and I don't see >> documentation for it.\ >>> nor let me specify key strength (only let me choose between medium and high >>> - I assume high is 4096 but I don't know, it didn't say) >> There's very little harm in getting a certificate and examining it to find >> out. You can destroy it later with no ill effect. > > I actually went for a more complex scenario, I've created my own CA complete > with CRL. > > 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. And > I have multiple e-mail accounts I want to do thus with. > > Could have done self-signed too but this at least allows me to revoke if a > device like laptop or phone w/ private key is stolen. > > Does mean those who want to confirm my messages have to import my root key > but that's for them to decide. > > 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. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos Well, your own CA’s certificates are basically self-signed. It’s of course a free country and you can do what you want - but in your case, you could just as well use GPG and be done with it. You could place your GPG public key where your root-certificate is placed and people could download and import that public key. The point of S/MIME is that there is a central authority to validate the owners of the certificates and no peer-to-peer fingerprint checking etc. a la GPG/PGP is needed. It does have better native support in MUAs, I’ll give you that. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] Where to buy S/MIME ??
On 11/27/2018 03:33 PM, Gordon Messmer wrote: On 11/25/18 5:35 AM, Alice Wonder wrote: The "free for personal" S/MIME from Comodo didn't work. Browser said it did but there was nothing to export for me to then import. I suspect it is because I used private browser window, Probably, yes. I've used that service in the past without issue. I really don't like the idea of a private key stored in browser anyway. And it never asked for a password to encrypt the private key Setting a password will protect all of the certificates stored by Firefox. Select: Preferences -> Privacy and Security -> Security Devices (under Certificates) -> Software Security Device -> Change password Chrome may have a similar option, but I don't see it and I don't see documentation for it.\ nor let me specify key strength (only let me choose between medium and high - I assume high is 4096 but I don't know, it didn't say) There's very little harm in getting a certificate and examining it to find out. You can destroy it later with no ill effect. I actually went for a more complex scenario, I've created my own CA complete with CRL. 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. And I have multiple e-mail accounts I want to do thus with. Could have done self-signed too but this at least allows me to revoke if a device like laptop or phone w/ private key is stolen. Does mean those who want to confirm my messages have to import my root key but that's for them to decide. 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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] Where to buy S/MIME ??
On 11/25/18 5:35 AM, Alice Wonder wrote: The "free for personal" S/MIME from Comodo didn't work. Browser said it did but there was nothing to export for me to then import. I suspect it is because I used private browser window, Probably, yes. I've used that service in the past without issue. I really don't like the idea of a private key stored in browser anyway. And it never asked for a password to encrypt the private key Setting a password will protect all of the certificates stored by Firefox. Select: Preferences -> Privacy and Security -> Security Devices (under Certificates) -> Software Security Device -> Change password Chrome may have a similar option, but I don't see it and I don't see documentation for it.\ nor let me specify key strength (only let me choose between medium and high - I assume high is 4096 but I don't know, it didn't say) There's very little harm in getting a certificate and examining it to find out. You can destroy it later with no ill effect. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 8 Public Beta Released
On 11/27/18 1:47 PM, Yan Li wrote: On 11/27/18 11:43 AM, Leon Fauster via CentOS wrote: Just wondering, are Software Collections on the trail of EOL now? Application Streams the new way to do? This answers my own question :-) https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ Also this one: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/ Being able to choose Python versions is great. Although I imagine that it will mean more work for our beloved CentOS buddies. The article title is a little misleading, so for those who don't have the time to read the full article and its references: There is no forced default python, but there are 3 different Pythons in RHEL 8 Beta: Platform-python: This is an off-to-the-side Python version for use by other RHEL 8 packages. Python 2.7: Offered as a module that can optionally be installed Python 3.6: Offered as a module that can optionally be installed The upshot is that RHEL 8 will be able to offer newer versions of Python in years to come, but end users can install the version that meets their needs and change the version over time as their needs change. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 8 Public Beta Released
On 11/27/18 11:43 AM, Leon Fauster via CentOS wrote: Just wondering, are Software Collections on the trail of EOL now? Application Streams the new way to do? This answers my own question :-) https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ Also this one: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/ Being able to choose Python versions is great. Although I imagine that it will mean more work for our beloved CentOS buddies. -- Yan Li ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] NBDE, clevis and tang for non-root disk
On Tue, Nov 27, 2018 at 8:06 PM mark wrote: > Sorry, I think you misunderstood. The key for root is *not* in > /etc/crypttab - that's only for the secondary ones. > > mark > > I understood correctly, just that you mentioning that one can put the key in the /etc/crypttab gave me the idea to check if the initramfs image will have the same content for crypttab. So now I have 2 working solutions: 1) /etc/crypttab on OS has a reference to the file that contains the key to decrypt the second volume (the key is on the encrypted root fs). I have checked and the initramfs /etc/crypttab has only the line for the root volume, without any reference to the second volume. The root volume gets decrypted by clevis+tang. The second volume is decrypted after the root volume is decrypted, /etc/crypptab is read and the key is found. 2) the initramfs /etc/crypttab was manually updated to add the line for the second volume. Clevis + tang will decrypt both the root fs and the second volume. I was surprised to find out the the /etc/crypttab in initramfs is different from the one in OS. So now I'm searching for the correct way to force dracut to include /etc/crypttab unchanged in the initramfs image. Radu ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 8 Public Beta Released
> Am 19.11.2018 um 15:35 schrieb Leon Fauster : > > >> Am 15.11.2018 um 15:37 schrieb Yan Li : >> >> https://www.redhat.com/en/blog/powering-its-future-while-preserving-present-introducing-red-hat-enterprise-linux-8-beta >> > > Just wondering, are Software Collections on the trail of EOL now? > > Application Streams the new way to do? This answers my own question :-) https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ -- LF ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7 install, "failed to IDENTIFY"
> Am 27.11.2018 um 19:05 schrieb mark : > > The install from a USB key fails. It's showing ata2:0.0 failed to > IDENTIFY. I've been searching online, and the only hint I have is that it > might not understand the controller. > > New Dell Optiplex 7050. > > Haanyone run into this? Just guessing: BIOS/UEFI: check if AHCI MODE is enabled ... -- LF ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] C7 install, "failed to IDENTIFY"
The install from a USB key fails. It's showing ata2:0.0 failed to IDENTIFY. I've been searching online, and the only hint I have is that it might not understand the controller. New Dell Optiplex 7050. Haanyone run into this? mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] NBDE, clevis and tang for non-root disk
Radu Radutiu wrote: > On Tue, Nov 27, 2018 at 3:14 PM mark wrote: > >> What we do is to have the encryption key of the secondary filesystem in >> /etc/crypttab, which is, of course, 600. As it boots, it decrypts from >> that as it mounts the rest of the system. >> > Thanks, this is working as expected and it gave me the hint needed to > find the actual problem. The problem is that the initramfs image generated > by dracut -f does not include the /etc/crypttab from the OS (it only > contains the entry for the root device). Once I have manually added the > other volumes in the /etc/crypttab file from the initramfs image, clevis > is able to decrypt all volumes. Now the question is why the generated > iniramfs image has a different /etc/crypttab. How can I specify > /etc/crypttab for the initramfs so that > furhter kernel updates will not replace it with the wrong file? > Sorry, I think you misunderstood. The key for root is *not* in /etc/crypttab - that's only for the secondary ones. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] NBDE, clevis and tang for non-root disk
On Tue, Nov 27, 2018 at 3:14 PM mark wrote: > What we do is to have the encryption key of the secondary filesystem in > /etc/crypttab, which is, of course, 600. As it boots, it decrypts from > that as > it mounts the rest of the system. > > mark > Thanks, this is working as expected and it gave me the hint needed to find the actual problem. The problem is that the initramfs image generated by dracut -f does not include the /etc/crypttab from the OS (it only contains the entry for the root device). Once I have manually added the other volumes in the /etc/crypttab file from the initramfs image, clevis is able to decrypt all volumes. Now the question is why the generated iniramfs image has a different /etc/crypttab. How can I specify /etc/crypttab for the initramfs so that furhter kernel updates will not replace it with the wrong file? Radu ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Tools/mechanisms for the management of access permissions in big filebased datasets
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] CentOS 7 package not present in Red Hat EL 7 - qt-assistant
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://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/package_manifest/chap-base-workstation-variant. 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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[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
