Discuss

discuss@lists.centos.org

3 participants
34748 discussions

Centos update 6.8 to 7
by Bachir Bachir 19 Jun '16

19 Jun '16

I downloaded Centos 7 and i want to update from local usb i created using dd if=cenots7 of=/dev/sdc i dont want to reinstall, i need just to update.What would be the best way to do so pleaseThanks muchBachir

2 1

Re: [CentOS] [Fwd: Re: https and self signed]
by James B. Byrne 18 Jun '16

18 Jun '16

On Fri, June 17, 2016 13:08, Valeri Galtsev wrote: > > We do not expire accounts until the person leaves the Department > and grace period passes. Then we do lock account and after some > time person's files are being deleted. This is the policy, and > this is what we do. The only time when account expiration is being > set is for undergraduate students who temporarily work with some > professor. For them expiration is being changed when the continue > to work with the professor next academic year. > > Is this not what everybody does? > Every end-user account, including my own, is given an expiry date six to twelve months in the future and that is extended at intervals as needed. The only exception to this are the root users which have no expiry date set. A forgotten and disused user account that retains access to your system is a significant risk in my opinion. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 1

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Fri, June 17, 2016 11:06, Walter H. wrote: > On 17.06.2016 16:46, James B. Byrne wrote: >> On Thu, June 16, 2016 13:53, Walter H. wrote: >>> On 15.06.2016 16:17, Warren Young wrote: >>>> but it also affects the other public CAs: you canât get a >>>> publicly-trusted cert for a machine without a publicly-recognized >>>> and -visible domain name. For that, you still need to use >>>> self-signed certs or certs signed by a private CA. >>>> >>> A private CA is the same as self signed; >>> >> No it is not. A private CA is as trustworthy as the organisation >> that >> operates it. No more and not one bit less. >> >> We operate a private CA for our domain and have since 2005. We >> maintain a public CRL strictly in accordance with our CPS and have >> our >> own OID assigned. > for your understanding: every root CA certificate is self signed; > any SSL certificate that was signed by a CA not delivered as built-in > token in a browser is the same as self-signed; > > > For your understanding, a self-signed certificate is one that has been signed by itself. Naturally ALL root certificates are self-signed. The self-signed root cert is then used to sign a subordinate CA issuing cert and that issuing cert is used to sign other subordinate CAs and / or end-user certs depending upon the permissions given it by the original signing certificate. This establishes the certificate trust chain. If website presents an actual self-signed cert to Firefox for example, it will refuse it. I suppose there is a way to circumvent this behaviour but I am not aware of it. If you present a certificate that is not self-signed but is signed by an authority whose root certificate chain is not in the trusted root store then Firefox gives you a warning -- as given in a preceding message 'net::ERR_CERT_AUTHORITY_INVALID' -- but it none-the-less allows you to accept the certificate as an exception and proceed to the website. If you do not want to get warnings and you trust the issuer then you can add their issuing CA cert chain to your trusted root certificate store. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

1 0

yum timeout ... (CentOS 6.8)
by Walter H. 18 Jun '16

18 Jun '16

Hello, the last times, when I tried to update, it get time outs; even when 'yum list' [root@host ~]# yum list Loaded plugins: fastestmirror, security Determining fastest mirrors epel/metalink | 13 kB 00:00 * base: centos.den.host-engine.com * epel: mirror.steadfast.net * extras: centos.den.host-engine.com * updates: centos.den.host-engine.com http://centos.den.host-engine.com/6/os/x86_64/repodata/repomd.xml: [Errno 12] Timeout on http://centos.den.host-engine.com/6 /os/x86_64/repodata/repomd.xml: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds') Trying other mirror. base | 3.7 kB 00:00 base/primary_db | 4.7 MB 00:03 epel | 4.3 kB 00:00 epel/primary_db | 5.8 MB 00:04 http://centos.den.host-engine.com/6/extras/x86_64/repodata/repomd.xml: [Errno 12] Timeout on http://centos.den.host-engine.c om/6/extras/x86_64/repodata/repomd.xml: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds') Trying other mirror. extras ... how or where can I reset this behavour, to have the really fastest mirros used? Thanks in advance, Walter

6 12

problem i didn't seeing list file new on centos
by alireza baghery 18 Jun '16

18 Jun '16

hi i have two server *CentOS 6.5* and *CentOS 5.9 * i have one *SAN Storage* on both servers but when i create file one of server (example Centos 6.5) Other Sever (Centos 5.9) do not see file and i must *umount* Disk to seeing files new how solve this problem format disk *EXT3* Tnx

3 2

CentOS Virtual Machine System Time
by Chris Olson 18 Jun '16

18 Jun '16

We run several CentOS 6 and CentOS 7 systems as virtual machines using VirtualBox on Windows 7. Most of these systems have continuous up time. The Windows 7 foundation platforms have no difficulty keeping accurate system time unless they are shut down for some reason, which is rare in our environment. We generally restart the Windows 7 machines at leastweekly rather than performing a complete power up restart. The CentOS virtual machines are shut down at times, usually to switch between versions that support various applications and for updates using yum. When the virtual CentOS systems are brought up, the system time always matches the Windows 7 host system time. We have recently noticed that after several hours, the CentOS system time has started to lag behind. The time difference in a week can be as much as four days. This system time lag has not always been immediately discovered by the user resulting in some annoying file date issues. Access to some web sites have also been a problem due to the "date in the future" issue. We are now on the lookout for this system time problem and restart the virtual machine to set the current date and time. Is this a common time problem when running CentOS as a virtual machine? Any suggestions regarding the cause if this problem and how to keep the CentOS system time locked to the host platform time would be greatly appreciated. Thanks.

3 2

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Thu, June 16, 2016 13:53, Walter H. wrote: > On 15.06.2016 16:17, Warren Young wrote: >> but it also affects the other public CAs: you canât get a >> publicly-trusted cert for a machine without a publicly-recognized >> and -visible domain name. For that, you still need to use >> self-signed certs or certs signed by a private CA. >> > A private CA is the same as self signed; > No it is not. A private CA is as trustworthy as the organisation that operates it. No more and not one bit less. We operate a private CA for our domain and have since 2005. We maintain a public CRL strictly in accordance with our CPS and have our own OID assigned. Our CPS and CRL together with our active, expired and revoked certificate inventory is available online at ca.harte-lyne.ca. Our CPS states that we will only issue certificates for our own domain and furthermore we only issue them for equipment and personnel under our direct control. In a few years DANE is going to destroy the entire market of 'TRUSTED' root CA's -- because really none of them are trust 'worthy' --. And that development is long overdue. When we reach that point many domains, if not most, will have their DNS forward zones providing TLSA RRs for their domain CA certificates and signatures. And most of those that do this are going to be running their own private CA's simply to maintain control of their certificates. Our DNS TLSA flags tell those that verify using DANE that our private CA is the only authority that can issue a valid certificate for harte-lyne.ca and its sub-domains. Compare that to the present case wherein any 'trusted' CA can issue a certificate for any domain whatsoever; whether they are authorised by the domain owner or not[1]. So in a future with DANE it will be possible to detect when an apparently 'valid' certificate is issued by a rogue CA. The existing CA structure could not have been better designed for exploitation by special interests. It has been and continues to be so exploited. Personally I distrust every one of the preloaded root CAs shipped with Firefox by manually removing all of their trust flags. I do the same with any other browser I use. I then add back in those trusts essential for my browser operation as empirical evidence warrants. So I must trust certain DigiCert certificates for GitHub and DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth. These I set the trust flags for web services only. The rest can go pound salt as we used to say. [1] https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-f… -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

5 6

Re: [CentOS] https and self signed
by Gordon Messmer 18 Jun '16

18 Jun '16

On 06/17/2016 07:56 AM, James B. Byrne wrote: > On Thu, June 16, 2016 14:09, Gordon Messmer wrote: >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > What evidence do you possess that supports this assertion and would > you care to share it with us? https://letsencrypt.org/2015/11/09/why-90-days.html

2 1

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree > with you in general (shorter period public key is exposed smaller > chance secret key brute-force discovered), Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant certificate generation and distribution simply increases the opportunities for key theft and tampering. Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. So having a guillotine date on a personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 1

Getting hibernate to work on a new CentOS 7.2.1115 install
by Globe Trotter 18 Jun '16

18 Jun '16

Hi, I am a new CentOS user (quite familiar with Fedora 1-23+) and I decided to try a new install of CentOS on a ASUS R503U. However, I can not get hibernate to work. I try: systemctl hibenaate and I get: Failed to execute operation: sleep verb not supported Btw, the problem does not go away with super-user. I was wondering how to get around this issue. I would like the abililty to hibernate and come back in the last state. Thanks!

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss