Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Jason Woods]

> On 2 Apr 2015, at 06:41, Always Learning  wrote:
> 
> 
>> On Thu, 2015-04-02 at 00:51 -0400, Lamar Owen wrote:
>> 
>> In my opinion, assigning sub-version numbers to what was originally
>> intended to be, by Red Hat, quarterly updates (almost Service Packs,
>> if you will, much like SGI's numbering of their Foundation and ProPack
>> products for the Altix server line) is what is illogical.  Of course,
>> the updates aren't quarterly any more, and other aspects of the
>> versioning have morphed and changed over the years since the RHAS days
>> (well, even back in certain branches of RHL 6.2, for that matter).
> 
> Whatever the original cause introducing sub-version numbering, that
> usage has become a clear progressive indicator of collections of updates
> within the major version.  

The new version numbering is too.

>>> Creating confusion where there was originally none is essentially silly.
>> 
>> I am not so easily confused by the new numbering;
> 
> I can not look at something labelled Centos 7.2169 and instantly know if
> it is Centos 7.1, 7.5 or even Centos 7.10.  What's the latest version of
> Centos 6 ?  Is it 6.32167 or 6.32782 or 6.32783 or should I be typing
> 6.23783 instead ? Confusion is not clarity.

Because CentOS 7.1 7.2 etc do not exist. 7.1503 etc does. These are also dates 
so 6.23783 would never exist. Though assuming a valid date, the bigger number 
would be the latest (year first then month so it is sortable.)

I don't recall the thread or even where but I do remember a discussion that 
7.1.1503 is not really semantic I think and potentially in itself confusing as 
you end up incrementing two numbers. The sub version becomes irrelevant as all 
the detail (point in time) lies with the date. The sub version becomes purely a 
remnant from RHEL with no specific purpose except to be a reminder.

>>> How many times has Johnny and others asserted that Centos is the same as
>>> RHEL ?
> 
>> The assertion is that CentOS is functionally equivalent to the upstream 
>> product.
> 
> If Centos is "functionally equivalent" to RHEL then common sense must
> dictate that the sub-version numbers should be compatible too.

I disagree. It's purely irrelevant in most cases.

Though one thing I do agree on is how to tell (roughly) which sources the 
CentOS release is based on. In which case the sub version number would be 
useful for academic reasons. For instance the release notes don't even mention 
RHEL 7.1 at all when I looked. Though you can usually match up the dates with 
the RHEL timeline so you can see when you're about to receive hundreds of 
updates.

So I can appreciate the concern somewhat on that regards. Maybe somewhere else 
needs to state it such as release notes and announcements (if those don't 
already.)

Jason
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Akemi Yagi]

On Wed, Apr 1, 2015 at 10:12 PM, Les Mikesell  wrote:

> Adding the date component means CentOS may release more than one iso
> per RH's minor versions.  There isn't much of a consistent
> relationship between the RH release and the subsequent Centos release
> other than 'sometime later when it is ready'.   So, given a set of
> Centos isos or even just the most recent, how would you know which RH
> release it is based on?  Download, install, and read the
> /etc/os-release file before finding out?   Or look up some other
> source of the missing information?

This could be that "some other source":

http://wiki.centos.org/Download
(go to the "Archived Versions" section)

Akemi
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[John R Pierce]

you guys sure get your panties in a bunch over something as silly as the 
iso file name.


if you don't like the name, rename it... sheesh.



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Always Learning]

On Thu, 2015-04-02 at 00:51 -0400, Lamar Owen wrote:

> Nor do I see it as an improvement.

Thank you for your considered response. If it is not an improvement,
then there is no reason for the change, is there ?

> In my opinion, assigning sub-version numbers to what was originally
>  intended to be, by Red Hat, quarterly updates (almost Service Packs,
>  if you will, much like SGI's numbering of their Foundation and ProPack
>  products for the Altix server line) is what is illogical.  Of course,
>  the updates aren't quarterly any more, and other aspects of the
>  versioning have morphed and changed over the years since the RHAS days
>  (well, even back in certain branches of RHL 6.2, for that matter).

Whatever the original cause introducing sub-version numbering, that
usage has become a clear progressive indicator of collections of updates
within the major version.  

> in reality the update number is meaningless for compatibility checks,
>  as it is more than possible to have a fully updated CentOS x system
>  that claims to be x.0 but has all the packages, save centos-release,
>  of the latest x.y; further, it is easily possible to install the
>  CentOS x.6 centos-release package on a completely unpatched x.0
>  system, making the contents of andy of the /etc/*-release files not
>  terribly useful for strict versioning.

I image the vast majority of Centos users will not risk doing
non-standard updates on their production systems so your above concern
is unlikely to occur.

> > Creating confusion where there was originally none is essentially silly.
> 
> I am not so easily confused by the new numbering;

I can not look at something labelled Centos 7.2169 and instantly know if
it is Centos 7.1, 7.5 or even Centos 7.10.  What's the latest version of
Centos 6 ?  Is it 6.32167 or 6.32782 or 6.32783 or should I be typing
6.23783 instead ? Confusion is not clarity.


> > How many times has Johnny and others asserted that Centos is the same as
> > RHEL ?

> The assertion is that CentOS is functionally equivalent to the upstream 
> product.

If Centos is "functionally equivalent" to RHEL then common sense must
dictate that the sub-version numbers should be compatible too.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 04/02/2015 01:12 AM, Les Mikesell wrote:

So, given a set of
Centos isos or even just the most recent, how would you know which RH
release it is based on?
Oh, one more minor point, and I know I'm probably in the minority here: 
for most of the cases where I use CentOS, I don't actually care which 
RHEL release it is 'based on.'  I just want 'latest CentOS [567]' for 
95% of my uses.  Well, 5 not as much now, but definitely 6 and 7.  I 
actually don't even have a case in production right now that is strict 
release-number-bound, but I did have a couple at one point.


So I don't care which update the CentOS ISO most closely corresponds 
with; it's CentOS, and the software I need to have work works, since it 
either works with or will soon work with latest RHEL.  (the Dell 
Poweredge stuff, for instance, where I'm 100% fully updated CentOS 6 at 
the moment).  Updates of course get vetted in testing first, but I try 
to not rely on software that is 
update-point-release-strict-number-bound.  And if I were to need that 
kind of strict release number binding, that particular machine would 
probably get Scientific Linux installed, since they do backports of 
certain things to earlier releases and let you stay at a particular 
update level while getting certain other updates. Although there are 
changes in RHEL 7.1 that are challenging things in that respect; see the 
threads on the SL lists related to SL7x and EPEL, for instance.


Of course, you can always trick out a release number bound setup by 
forcing a particular centos-release package to be the one that is 
installed, if it is a 'paper' requirement rather than a real requirement 
(which I have run into before).


But I know others have other requirements; YMMV and all that.  I'm just 
stating what the reality is for my uses at the moment.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 04/02/2015 01:12 AM, Les Mikesell wrote:
Adding the date component means CentOS may release more than one iso 
per RH's minor versions. 


Newsflash: they already are, just not in the main releases trees. Look 
in http://buildlogs.centos.org/rolling/7/isos/x86_64/


I previously used the 20150228 CentOS 7 rolling Everything ISO to do a 
reinstall; worked great.  Nice to not have to grab hundreds of MB of 
updates right out of the box.  This was on the CentOS-Announce list, 
incidentally.


There isn't much of a consistent relationship between the RH release 
and the subsequent Centos release other than 'sometime later when it 
is ready'. So, given a set of Centos isos or even just the most 
recent, how would you know which RH release it is based on? 


Hmm, maybe the name of the directory it is in and the link in the 
release notes?  I also notice that the rolling point in time images have 
the full four digit year as well as month and day, whereas the 
'functionally equivalent to a particular Red Hat update release' image 
has a two digit year, the month, but no day.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Les Mikesell]

On Wed, Apr 1, 2015 at 11:51 PM, Lamar Owen  wrote:
>>
> I am not so easily confused by the new numbering; what the ISO is named is
> orthogonal to what it contains, at least in my mind.

Adding the date component means CentOS may release more than one iso
per RH's minor versions.  There isn't much of a consistent
relationship between the RH release and the subsequent Centos release
other than 'sometime later when it is ready'.   So, given a set of
Centos isos or even just the most recent, how would you know which RH
release it is based on?  Download, install, and read the
/etc/os-release file before finding out?   Or look up some other
source of the missing information?

-- 
  Les Mikesell
lesmikses...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Kernel panic, CentOS 7.1503 fully updated, with executing gkrellm.

[Lamar Owen]

Just a heads up, since I know gkrellm is in EPEL and not in the main 
CentOS repos.  However, something fairly fundamental has changed, as 
prior to updating, gkrellm worked fine, but now every time I execute 
gkrellm the kernel panics.


I'm going to triage on a different machine, as the panic corrupted at 
least one system library used by nautilus, but rpm -Va is your friend in 
these situations, and yum reinstall is its close kin.  So I would prefer 
to duplicate on a burner machine, and I'll try to get a snapshot of the 
panic.


If anyone else wants to try to reproduce, simply try installing the 
current gkrellm from EPEL on a fully updated CentOS 7 machine and see if 
it panics on you.  I kindof hope it's local to my machine and its 
configuration (/home is LUKS, for instance), and it would be great if 
someone could verify that.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 04/01/2015 08:12 PM, Always Learning wrote:

1. What is the logically reason for this alleged "improvement" ?


I never said it was an improvement.  I just said that I didn't think it 
was that big of a deal, and it boggles my mind that people are calling a 
change of an ISO's file name 'unwise' and even comparing it to a 
Microsoft move.  I just don't see it as being that big of a problem.  
Nor do I see it as an improvement.  But the question was asked about 
where such a change might have been discussed, and I pointed to the long 
and drawn out centos-devel thread in which the background for the 
date-based numbering was beaten to death (and beyond).  The CentOS devs 
have stated that the CentOS Board voted on it, and they have the 
decision-making power to do so.  And they are all reasonable people.



2. How are users of all types, from all around the world, benefiting
from this change ?
This change makes it unequivocally clear that CentOS 7.1503 is not 
exactly the same as upstream RHEL 7.1, although it is functionally 
equivalent (where the meaning of functionally equivalent has been hashed 
to death, too, but it basically means binary-compatible but not 
necessarily binary-identical).  Whether you consider that a benefit or 
not is up to you.  I'm personally neutral on the issue.


Consolidating two replies:
On 04/01/2015 07:58 PM, Always Learning wrote:

On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:


On 04/01/2015 03:33 PM, Always Learning wrote:
(1) removing sub-version numbers is wrong; and ...


That is a matter of opinion.  In my opinion, assigning sub-version 
numbers to what was originally intended to be, by Red Hat, quarterly 
updates (almost Service Packs, if you will, much like SGI's numbering of 
their Foundation and ProPack products for the Altix server line) is what 
is illogical.  Of course, the updates aren't quarterly any more, and 
other aspects of the versioning have morphed and changed over the years 
since the RHAS days (well, even back in certain branches of RHL 6.2, for 
that matter).


So you could read '7.1' as 'version 7 service pack 1.'  My opinion is 
that sub-version numbers give a mistaken impression that the update 
number is a real 'version' when it was not originally so. Further, in 
reality the update number is meaningless for compatibility checks, as it 
is more than possible to have a fully updated CentOS x system that 
claims to be x.0 but has all the packages, save centos-release, of the 
latest x.y; further, it is easily possible to install the CentOS x.6 
centos-release package on a completely unpatched x.0 system, making the 
contents of andy of the /etc/*-release files not terribly useful for 
strict versioning.


It is my opinion, although it's not a vehement opinion, that beginning 
the x.y practice is what was illogical.  But it was done, and it is 
over, and I have more important things to do than gripe over semantics 
such as that.



Creating confusion where there was originally none is essentially silly.


I am not so easily confused by the new numbering; what the ISO is named 
is orthogonal to what it contains, at least in my mind.



How many times has Johnny and others asserted that Centos is the same as
RHEL ?
The assertion is that CentOS is functionally equivalent to the upstream 
product.  It is not 'the same as' nor can it be and still remove the 
trademarked branding of the upstream release.  It is binary compatible 
without being binary identical. And as the meaning of 'binary 
compatible' has also been hashed to death, I'll not further clutter the 
traffic on this list about what it means.  It's easy enough to read the 
centos-devel archives to see for yourself.



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Always Learning]

On Wed, 2015-04-01 at 21:51 -0500, Valeri Galtsev wrote:

> Changing of naming structure from self explanatory to obscure is not clever 
> either.

That single sentence is the essence of the concern I share with others.

> 2. Processor chip manufacturers with their chip notations (AMD was the
> first one who got me annoyed, even though I like them more than Intel)

I have always preferred AMD to Intel :-)

Everyone makes mistakes, me too. Simply reverting the naming structure
can be done without embarrassment. After all, we are all part of the
same Centos family.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Valeri Galtsev]

On Wed, April 1, 2015 6:58 pm, Always Learning wrote:
>
> On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:
>
>> On 04/01/2015 03:33 PM, Always Learning wrote:
>> > If someone (currently anonymous) at Centos says abandon sub-version
>> > numbers and introduce an illogical ISOs naming structure, a wise
>> person
>> > will ignore that command.
>>
>> So, in essence you're saying that the builders of the OS that you use
>> and trust for daily tasks are unwise, right?  Sounds to me like you
>> might want to use something different.
>
> No I am not as can be conspicuously seen in what I wrote. Lamar your
> introduction of non-relevant matters can not detract from the essential
> point I made:-
>
> (1) removing sub-version numbers is wrong; and
>
> (2) changing the ISO naming structure from
> {major version}-{sub-version}-{build number}-{architecture}-{media}.iso
> is an illogical unwise change because anyone looking at
>
> {major version}-{sub-version}
>
> instantly knows, for example, that is Centos 7.1 whereas
>
> CentOS-7-1503-x86_64-DVD.iso
>
> is baffling and one is then required to build and maintain a translation
> table to convert '1503' into Centos 7.1. That is frankly bonkers.
>
> Creating confusion where there was originally none is essentially silly.

I agree with all of this. I'm more neutral to these changes merely because
I don't rely as much on Linux as I did in the past. Still making change
where there is no need for one is a bad practice. Changing of naming
structure from self explanatory to obscure is not clever either.

Here are examples of well known ones who do these ("wrong") things:

1. Microsoft: often re-shuffles names and locations of yet the same tools
(making justifiable new Administrator certifications, and making Windows
admins look smart as they learn by heart stupid things like new locations
of tools...)

2. Processor chip manufacturers with their chip notations (AMD was the
first one who got me annoyed, even though I like them more than Intel)

Somebody, continue the list.

Does everybody think that CentOS with this change joins a good company (as
I said I don't care much, I'll survive ;-)

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Always Learning]

On Wed, 2015-04-01 at 17:10 -0400, Lamar Owen wrote:

> I'm just experiencing a bit of disbelief that people are 
> getting hung up over the file's name being the slightest bit 
> unexpectedly different, that's all.

1. What is the logically reason for this alleged "improvement" ?

2. How are users of all types, from all around the world, benefiting
from this change ?


R.s.v.p.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Always Learning]

On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:

> On 04/01/2015 03:33 PM, Always Learning wrote:
> > If someone (currently anonymous) at Centos says abandon sub-version
> > numbers and introduce an illogical ISOs naming structure, a wise person
> > will ignore that command.
> 
> So, in essence you're saying that the builders of the OS that you use 
> and trust for daily tasks are unwise, right?  Sounds to me like you 
> might want to use something different.

No I am not as can be conspicuously seen in what I wrote. Lamar your
introduction of non-relevant matters can not detract from the essential
point I made:-

(1) removing sub-version numbers is wrong; and

(2) changing the ISO naming structure from
{major version}-{sub-version}-{build number}-{architecture}-{media}.iso
is an illogical unwise change because anyone looking at 

{major version}-{sub-version}

instantly knows, for example, that is Centos 7.1 whereas

CentOS-7-1503-x86_64-DVD.iso 

is baffling and one is then required to build and maintain a translation
table to convert '1503' into Centos 7.1. That is frankly bonkers.

Creating confusion where there was originally none is essentially silly.

How many times has Johnny and others asserted that Centos is the same as
RHEL ?  More puzzling is the complete absence of logic for this
detrimental removal of the sub-version number.

> It is impossible to satisfy everyone.

I do not remember reading on this list any criticisms of the former, now
abandoned, practise of using:-

{major version}-{sub-version}-{build number}-{architecture}-{media}.iso
 
-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Karanbir Singh]

On 01/04/15 18:56, David A. De Graaf wrote:
> Today I did a yum upgrade to my kvm'ized Centos 7 test machine
> (perhaps a bad day to do such a thing) and received new kernel
> vmlinuz-3.10.0-229.1.2.el7.x86_64, among many other things. 
> When I rebooted, I was asked to confirm (or renew, or some such)
> my license.  My LICENSE ???
> 
> I was booting in text mode and the actions required were
> a) unfamiliar, and b) hard to understand.
> 
> As I recall, I had to read the EULA - a worrisomely Microsoftian 
> demand - and accept it.  Of course, the terms were pretty benign.
> Then I had to continue.  I can't remember the exact language.
> Of course, now when I reboot, all this cruft is gone.
> 
> Is this a cute April Fool joke?
> If not, WTF is going on?
> 

Let me dig into some details :

When a new install is run, anaconda leaves behind content that allows
the following reboot process to run through some tasks before control is
handed back to the user - eg. setting up selinux / kdump / users and
also redoing some previously done tasks. again eg. when the storage
backend changes or a new layer is introduced.

one of these tasks is to pass through the EULA, implicitly saying you
are ok with it. the CentOS Linux EULA has always been a case of 'no
gurantee, no warranty, the sla is that there is no sla'. But I am sure
you are aware of that, since you already had a centos install to start with.

For this release, we've disabled some of the tasks that get run - but
retained the code that runs these tasks, since its actually required to
be run in some cases ( eg. with firstboot --reconfig is called ).

The option I had was to either strip out the eula process, or do
something more drastic : like not have it run at all, unless a user
asked for it to be run. And in that case, force it to always run in
LANG=C ( there are some incomple translations in the mix as well ).

I took the second option - and disabled this code completely by default,
unless its implicitly asked for - in some cases, this can be down to
system changes ( the only one i was able to find was when the backing
storage changes in a virtualised environ - but mostly large public
clouds, i wonder what your storage format is that caused this ).

the text UI isnt easy to work through, I totally agree.

In the coming days, I will try and strip out the EULA acceptance bits
from the code and request Johnny to issue an update for this.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Johnny Hughes]

On 04/01/2015 02:36 PM, Digimer wrote:
> On 01/04/15 01:56 PM, David A. De Graaf wrote:
>> Today I did a yum upgrade to my kvm'ized Centos 7 test machine
>> (perhaps a bad day to do such a thing) and received new kernel
>> vmlinuz-3.10.0-229.1.2.el7.x86_64, among many other things. 
>> When I rebooted, I was asked to confirm (or renew, or some such)
>> my license.  My LICENSE ???
>>
>> I was booting in text mode and the actions required were
>> a) unfamiliar, and b) hard to understand.
>>
>> As I recall, I had to read the EULA - a worrisomely Microsoftian 
>> demand - and accept it.  Of course, the terms were pretty benign.
>> Then I had to continue.  I can't remember the exact language.
>> Of course, now when I reboot, all this cruft is gone.
>>
>> Is this a cute April Fool joke?
>> If not, WTF is going on?
> 
> RHEL 7, which is upstream of CentOS 7, has a license component. I
> suspect that given CentOS's goal of replicating RHEL "warts and all",
> this is a by-product of that. When I played with CentOS 7 GUI install,
> the "license" is basically "it is GPL, have a nice day" [ Accept ].
> 

This is indeed the case, RHEL 7.1 requires one to accept the license on
initial boot up.

The package that drives that was firstboot but is no initial-setup.  In
our 7.1503 testing, CLI based installs did not require accepting our
EULA, but GUI based installs do require accepting the EULA before
continuing.

But in any event, both licenses and EULAs are very important.  In the
case of CentOS 7 Linux, this is the EULA:

==

CentOS-7 EULA

CentOS-7 comes with no guarantees or warranties of any sorts,
either written or implied.

The Distribution is released as GPLv2. Individual packages in the
distribution come with their own licenses.

==

As you can see, the overall License of CentOS is GPLv2 and individual
packages have individual licenses.

But make no mistake, the fact that CentOS Linux uses open source
licenses is very important.  Without those licenses and adherence to
them, CentOS Linux could not exist.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Lamar Owen]

On 04/01/2015 04:55 PM, John R Pierce wrote:


I generally do minimal installs and I don't recall ever seeing any 
first boot license prompt.   is this a 'feature' only if you've 
installed the desktop GUI ?




Could be; all of the many installs of C7 I've done thus far have needed 
the GUI for one reason or another.  I do remember when installing RHEL 
6.1 a few years back and selecting 'Server with a GUI' (or similar) that 
the firstboot license prompt came up in text mode, but none of the C6 
installs I've done in text mode have gone through the firstboot 
'license' agreement (or make a normal user, or any of the other things 
firstboot can do, like network configuration in text mode for a 
NetworkManager-controlled NIC) thing.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 04/01/2015 04:43 PM, Alain Péan wrote:

Le 01/04/2015 22:15, Lamar Owen a écrit :

It is impossible to satisfy everyone.


So, you refuse to hear your users, who have stated good arguments, for 
something that is not very difficult to change, the name of the iso, 
which is not coherent with the 7.0 name and confusing ? 


It is only confusing if you let it confuse you.  I've been around this 
thing long enough to remember when the distribution ISO's carried 
wonderful names like 'seawolf-i386-disc1.iso' (study a bit and you'll 
get the joke).  I'm just experiencing a bit of disbelief that people are 
getting hung up over the file's name being the slightest bit 
unexpectedly different, that's all.


And my comment that 'it is impossible to satisfy everyone' is a bit of a 
USA idiom, typically quoted as "You can't please anyone all the time, 
nor can you please everyone any time" or similar.


Yes, not very wise... Karanbir corrected very quickly the content of 
the redhat-release file, because it was totally different from 7.0, 
and broke a lot of scripts and applications.
The issue of the content of redhat-release was a serious and valid one 
that actually broke stuff; the ISO name being different from expected 
doesn't break stuff. If the ISO name broke stuff, then that would be 
different, and it would have already been fixed.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[John R Pierce]

On 4/1/2015 1:46 PM, Lamar Owen wrote:
This is normal for the first boot after installation, but it shouldn't 
have done this after an update.  It didn't do that here after the 
update; it did do that on the firstboot after install. Unlike many 
others here, CentOS 7 is my primary, every day, work and personal 
desktop OS of choice, and so it's just one of those normal 'first time 
through' things after install. 


I generally do minimal installs and I don't recall ever seeing any first 
boot license prompt.   is this a 'feature' only if you've installed the 
desktop GUI ?




--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Lamar Owen]

On 04/01/2015 01:56 PM, David A. De Graaf wrote:

When I rebooted, I was asked to confirm (or renew, or some such)
my license.  My LICENSE ???

... I can't remember the exact language.
Of course, now when I reboot, all this cruft is gone.


This is normal for the first boot after installation, but it shouldn't 
have done this after an update.  It didn't do that here after the 
update; it did do that on the firstboot after install. Unlike many 
others here, CentOS 7 is my primary, every day, work and personal 
desktop OS of choice, and so it's just one of those normal 'first time 
through' things after install.


The LICENSE in question is the GPL, as I recall.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Alain Péan]

Le 01/04/2015 22:15, Lamar Owen a écrit :
So, in essence you're saying that the builders of the OS that you use 
and trust for daily tasks are unwise, right?  Sounds to me like you 
might want to use something different.



just the change will satisfy everyone.



It is impossible to satisfy everyone.


So, you refuse to hear your users, who have stated good arguments, for 
something that is not very difficult to change, the name of the iso, 
which is not coherent with the 7.0 name and confusing ? Yes, not very 
wise... Karanbir corrected very quickly the content of the 
redhat-release file, because it was totally different from 7.0, and 
broke a lot of scripts and applications.


Alain
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[m . roth]

Valeri Galtsev wrote:
> On Wed, April 1, 2015 11:09 am, Andrew Holway wrote:
>>>
>>> This is all interesting, but I've got one dumb question: why do you
>>> need to decrypt it?
>>
>> In the UK we have a law which give you the right to remain silent; so as
>> not to incriminate yourself. I think in the US its known as "taking the
>> fifth".
>
> Indeed.
>
> But I for one can deduce the answer, assuming the OP knows everything I
> know or more (sorry for abbr.; Original Poster I had to say). Here is my
> speculation:

*sigh*

I was deliberately avoiding the reasons I could think of, so that the OP
might tell us without the witness being lead

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 04/01/2015 03:33 PM, Always Learning wrote:

If someone (currently anonymous) at Centos says abandon sub-version
numbers and introduce an illogical ISOs naming structure, a wise person
will ignore that command.


So, in essence you're saying that the builders of the OS that you use 
and trust for daily tasks are unwise, right?  Sounds to me like you 
might want to use something different.



just the change will satisfy everyone.



It is impossible to satisfy everyone.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] can't mount an LVM volume inCentos 5.10

[Dave Stevens]

I have a degraded raid array (originally raid-10, now only two drives)  
that contains an LVM volume. I can see in the appended text that the  
Xen domains are there but I don't see how to mount them. No doubt this  
is just ignorance on my part but I wonder if anyone would care to  
direct me? I want to be able to retrieve dom-0 and one of the dom-Us  
to do data recovery, the others are of no interest.


Suggestions? Will rtfm if directed.

Dave

excerpt from failed mount attempts

--- starting here 

root@Microknoppix:/home/knoppix# vgchange -ay bulkley
  Volume group "bulkley" not found
root@Microknoppix:/home/knoppix# vgchange -ay /dev/VolGroup00/bulkley
  Invalid volume group name: VolGroup00/bulkley
  Run `vgchange --help' for more information.
root@Microknoppix:/home/knoppix# vgimport -f VolGroup00
  Volume group "VolGroup00" is not exported
root@Microknoppix:/home/knoppix# vgchange -ay VolGroup00
  8 logical volume(s) in volume group "VolGroup00" now active
root@Microknoppix:/home/knoppix# lvscan
  ACTIVE'/dev/VolGroup00/Dom0' [40.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/babine' [100.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/centos-template' [100.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/bulkley-old' [100.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/ubuntu' [10.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/morice' [200.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/oldserver' [80.00 GiB] inherit
  ACTIVE'/dev/VolGroup00/bulkley' [100.00 GiB] inherit
root@Microknoppix:/home/knoppix# mount /dev/mapper/VolGroup00 aa
mount: special device /dev/mapper/VolGroup00 does not exist
root@Microknoppix:/home/knoppix# mount /dev/mapper/bulkley aa
mount: special device /dev/mapper/bulkley does not exist
root@Microknoppix:/home/knoppix# mount /dev/mapper/dev/VolGroup00 aa
mount: special device /dev/mapper/dev/VolGroup00 does not exist
root@Microknoppix:/home/knoppix# mount /dev/mapper/dev/VolGroup00/bulkley aa
mount: special device /dev/mapper/dev/VolGroup00/bulkley does not exist
root@Microknoppix:/home/knoppix# mount /dev/mapper/dev/VolGroup00/LogVol00 aa
mount: special device /dev/mapper/dev/VolGroup00/LogVol00 does not exist
root@Microknoppix:/home/knoppix# mount  
/dev/mapper/dev/VolGroup00/LogVol00/bulkley aa
mount: special device /dev/mapper/dev/VolGroup00/LogVol00/bulkley does  
not exist

root@Microknoppix:/home/knoppix# mount /dev/VolGroup00/LogVol00/bulkley aa
mount: special device /dev/VolGroup00/LogVol00/bulkley does not exist

--
"As long as politics is the shadow cast on society by big business,
the attenuation of the shadow will not change the substance."

-- John Dewey





___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SEmodule dependency hell.

[Andrew Holway]

I used the command: semanage port -m -t http_port_t -p tcp 8000
to relabel a port. perhaps you could try:
"semanage port -m -t unconfined_t -p tcp 8000"
Failing that; would it work to run your application in the httpd_t domain?

Ta,

Andrew

On 1 April 2015 at 18:23, James B. Byrne  wrote:

> I want you all to see what I went through trying to simply reassign
> (unsuccessfully) the context of a well-known port.
>
> To the best of my ability to recall none of the packages mentioned
> below are even installed on the host in question.  Why are these
> dependices preventing me from removing a disused SELinux policy.
>
> I have done exactly that, reassign port contexts, in the past without
> encountering this situation.  So it has to be a recent development.  I
> am not against SELinux.  We use it extensively.  But this is not
> security it is simply BS.
>
> It is stuff like this that causes people to say just turn selinux off
> altogether.
>
>
> semodule -r apache
> libsepol.print_missing_requirements: awstats's global requirements
> were not met: type/attribute httpd_log_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r awstats
>
> semodule -r apache
> libsepol.print_missing_requirements: bugzilla's global requirements
> were not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r bugzilla
>
> semodule -r apache
> libsepol.print_missing_requirements: cobbler's global requirements
> were not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r cobbler
>
> semodule -r apache
> libsepol.print_missing_requirements: collectd's global requirements
> were not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r collectd
>
> semodule -r apache
> libsepol.print_missing_requirements: git's global requirements were
> not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r git
>
> semodule -r apache
> libsepol.print_missing_requirements: gpg's global requirements were
> not met: type/attribute httpd_sys_content_t (No such file or
> directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r gpg
>
> semodule -r apache
> libsepol.print_missing_requirements: mediawiki's global requirements
> were not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r mediawiki
>
> semodule -r apache
> libsepol.print_missing_requirements: munin's global requirements were
> not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r munin
>
> semodule -r apache
> libsepol.print_missing_requirements: nagios's global requirements were
> not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r nagios
>
> semodule -r apache
> libsepol.print_missing_requirements: w3c's global requirements were
> not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r apache
> libsepol.print_missing_requirements: webadm's global requirements were
> not met: type/attribute httpd_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r webadm
>
> semodule -r apache
> libsepol.print_missing_requirements: webalizer's global requirements
> were not met: type/attribute httpd_sys_content_t (No such file or
> directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or directory).
> semodule:  Failed!
>
> semodule -r webalizer
>
> semodule -r apache
> libsepol.context_from_record: type httpd_openshift_script_exec_t is
> not defined
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert
> unconfined_u:object_r:httpd_openshift_script_exec_t:s0 to sid
> invalid context unconfined_u:object_r:httpd_openshift_script_exec_t:s0
> libsemanage.semanage_install_active: setfiles returned error code 1.
> semodule:  Failed!
>
> se

[CentOS] Import Nautilus file notes from C6 Gnome to C7 Mate

[Frank Cox]

With C6 Gnome and C7 Mate you can right-click on a file icon, select 
Properties, select Notes, and write notes about your file.

Does anyone know if those notes can be directly transferred between C6 Gnome 
and C7 Mate?  I'm looking into upgrading someone's desktop machine to C7 and 
she has a lot of notes attached to her files that she doesn't want to lose.

After doing a bit of experimenting, I think the notes are actually stored in a 
file named ~/.local/share/gvfs-metadata/home

Can I just copy that "home" file into the new C7 Mate desktop and have the file 
notes move in automatically, or do I have to somehow extract the notes and 
re-import them?

Any suggestions will be appreciated.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Les Mikesell]

On Wed, Apr 1, 2015 at 2:23 PM, Peter  wrote:
>>
> My point is that there was a claim by the board that this particular
> change was discussed extensively on the -devel list.  If it was then it
> should be quite easy to point out the post(s) in the archives where this
> particular discussion tool place.
>

The addition of a date reference makes sense to allow and identify
respins within the life of a minor rev, but...

There were alternatives proposed, like:
http://lists.centos.org/pipermail/centos-devel/2014-June/010940.html
but I can't see any 'discussion' about why the weird concept of using
the minor .0 in the initial iso name but dropping it out of subsequent
versions was better or chosen.

I see the directory created on vault.centos.org is surprisingly sane,
though, retaining the useful minor rev number.

-- 
Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Digimer]

On 01/04/15 01:56 PM, David A. De Graaf wrote:
> Today I did a yum upgrade to my kvm'ized Centos 7 test machine
> (perhaps a bad day to do such a thing) and received new kernel
> vmlinuz-3.10.0-229.1.2.el7.x86_64, among many other things. 
> When I rebooted, I was asked to confirm (or renew, or some such)
> my license.  My LICENSE ???
> 
> I was booting in text mode and the actions required were
> a) unfamiliar, and b) hard to understand.
> 
> As I recall, I had to read the EULA - a worrisomely Microsoftian 
> demand - and accept it.  Of course, the terms were pretty benign.
> Then I had to continue.  I can't remember the exact language.
> Of course, now when I reboot, all this cruft is gone.
> 
> Is this a cute April Fool joke?
> If not, WTF is going on?

RHEL 7, which is upstream of CentOS 7, has a license component. I
suspect that given CentOS's goal of replicating RHEL "warts and all",
this is a by-product of that. When I played with CentOS 7 GUI install,
the "license" is basically "it is GPL, have a nice day" [ Accept ].

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Always Learning]

On Thu, 2015-04-02 at 08:23 +1300, Peter wrote:


> My point is that there was a claim by the board that this particular
> change was discussed extensively on the -devel list.  If it was then it
> should be quite easy to point out the post(s) in the archives where this
> particular discussion tool place.

If someone at Centos says put your hand in the fire, a wise person will
ignore that command.
 
If someone (currently anonymous) at Centos says abandon sub-version
numbers and introduce an illogical ISOs naming structure, a wise person
will ignore that command.

A simple policy revision will make millions of Centos users smile. No
apologies or excuses necessary - just the change will satisfy everyone.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Always Learning]

On Wed, 2015-04-01 at 18:09 +0200, Andrew Holway wrote:
> >
> > This is all interesting, but I've got one dumb question: why do you need
> > to decrypt it?
> >
> 
> In the UK we have a law which give you the right to remain silent; so as
> not to incriminate yourself. I think in the US its known as "taking the
> fifth".

English law states silence, in response to an arrest caution, can be
used against the arrested person at their criminal trial.  The English
system permits prosecutors to mislead and confuse the jury and to
blatantly lie about the defendant. In those circumstances has an alleged
"Right not to self-incriminate" any practical usefulness ?

Follow-ups, if any, off the list, please.

-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Peter]

On 04/02/2015 03:29 AM, Lamar Owen wrote:
> On 03/31/2015 11:11 PM, Peter wrote:
>> Can you please point me to the centos-devel thread that discussed
>> changing the iso naming convention from CentOS-7.1-1503-x86_64-DVD.iso
>> to CentOS-7-x86_64-DVD-1503.iso? I must have missed it because I saw
>> no mention of this change until today.
> The first thread along these lines starts at
> http://lists.centos.org/pipermail/centos-devel/2014-June/010444.html
> 
> It is a long thread, as you should know, since you participated in it.

Yes I did, which is why I find it strange that making this particular
change to the ISO name format is considered to have come from that
thread.  I don't recall seeing that exact change discussed, but I coudl
be wrong, it was a long thread and I probably didn't read the whole
thing in detail.

> The key post in the thread, in my opinion, is at
> http://lists.centos.org/pipermail/centos-devel/2014-June/010944.html

I still don't see anything in that post about changing the iso name as
mentioned above.  Do feel free to point out specifics to me.

> My takeaway is that the ISO name for 7.1406 was an aberration, and that
> this is the new paradigm going forward.  But I'll also reserve the right
> to be wrong.

My point is that there was a claim by the board that this particular
change was discussed extensively on the -devel list.  If it was then it
should be quite easy to point out the post(s) in the archives where this
particular discussion tool place.


Peter
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] os-release file doesn't match upstream?

[Phelps, Matthew]

On Wed, Apr 1, 2015 at 2:23 PM, Stephen Harris  wrote:

> On a fully patched C7 machine...
>
>   % cat /etc/redhat-release
>   CentOS Linux release 7.1.1503 (Core)
>
>   % cat /etc/os-release
>   NAME="CentOS Linux"
>   VERSION="7 (Core)"
>   ID="centos"
>   ID_LIKE="rhel fedora"
>   VERSION_ID="7"
>   PRETTY_NAME="CentOS Linux 7 (Core)"
>   ANSI_COLOR="0;31"
>   CPE_NAME="cpe:/o:centos:centos:7"
>   HOME_URL="https://www.centos.org/";
>   BUG_REPORT_URL="https://bugs.centos.org/";
>
>   CENTOS_MANTISBT_PROJECT="CentOS-7"
>   CENTOS_MANTISBT_PROJECT_VERSION="7"
>   REDHAT_SUPPORT_PRODUCT="centos"
>   REDHAT_SUPPORT_PRODUCT_VERSION="7"
>
> In particular note the version ID is 7
>
> On a RedHat machine:
>   % cat /etc/redhat-release
>   Red Hat Enterprise Linux Server release 7.1 (Maipo)
>
>   % cat /etc/os-release
>   NAME="Red Hat Enterprise Linux Server"
>   VERSION="7.1 (Maipo)"
>   ID="rhel"
>   ID_LIKE="fedora"
>   VERSION_ID="7.1"
>   PRETTY_NAME="Red Hat Enterprise Linux Server 7.1 (Maipo)"
>   ANSI_COLOR="0;31"
>   CPE_NAME="cpe:/o:redhat:enterprise_linux:7.1:GA:server"
>   HOME_URL="https://www.redhat.com/";
>   BUG_REPORT_URL="https://bugzilla.redhat.com/";
>
>   REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
>   REDHAT_BUGZILLA_PRODUCT_VERSION=7.1
>   REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
>   REDHAT_SUPPORT_PRODUCT_VERSION="7.1"
>
> Here the version ID is 7.1; different to CentOS.
>
> Is this a bug or is it deliberate?
>
> --
>
> rgds
> Stephen
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


It's deliberate.

Apparently the CentOS board went ahead and made major changes, different
from RedHat, to the release names for CentOS 7 based on a thread in
centos-devel.

I find no solicitations for feedback on this list, or the centos-announce
list. (If I've missed one, let me know!)

It's a decision I disagree with vehemently, and would have happily made my
objections known had I heard. As a "customer" of CentOS, I do not
participate in the centos-devel list. Obviously considering the messages
cropping up on this list today, I am not alone.


-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphe...@cfa.harvard.edu, http://www.cfa.harvard.edu
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[Les Mikesell]

On Wed, Apr 1, 2015 at 1:17 PM, John R Pierce  wrote:
> On 4/1/2015 10:56 AM, David A. De Graaf wrote:
>>
>> Is this a cute April Fool joke?
>> If not, WTF is going on?
>
>
>
> hmm, I wasn't even watching the console of a C7 VM running under esxi, it
> rebooted in about 10 seconds to 7.1, no such EULA afaik.

I thought that was something you only see on the first console login
after the install - but it shouldn't repeat after an update.   Most of
our systems are installed remotely by someone else and managed over
ssh after that - so no one is ever going to be at a console to see it.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] os-release file doesn't match upstream?

[Stephen Harris]

On a fully patched C7 machine...

  % cat /etc/redhat-release
  CentOS Linux release 7.1.1503 (Core)

  % cat /etc/os-release
  NAME="CentOS Linux"
  VERSION="7 (Core)"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="7"
  PRETTY_NAME="CentOS Linux 7 (Core)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:7"
  HOME_URL="https://www.centos.org/";
  BUG_REPORT_URL="https://bugs.centos.org/";

  CENTOS_MANTISBT_PROJECT="CentOS-7"
  CENTOS_MANTISBT_PROJECT_VERSION="7"
  REDHAT_SUPPORT_PRODUCT="centos"
  REDHAT_SUPPORT_PRODUCT_VERSION="7"
  
In particular note the version ID is 7

On a RedHat machine:
  % cat /etc/redhat-release
  Red Hat Enterprise Linux Server release 7.1 (Maipo)

  % cat /etc/os-release
  NAME="Red Hat Enterprise Linux Server"
  VERSION="7.1 (Maipo)"
  ID="rhel"
  ID_LIKE="fedora"
  VERSION_ID="7.1"
  PRETTY_NAME="Red Hat Enterprise Linux Server 7.1 (Maipo)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:redhat:enterprise_linux:7.1:GA:server"
  HOME_URL="https://www.redhat.com/";
  BUG_REPORT_URL="https://bugzilla.redhat.com/";

  REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
  REDHAT_BUGZILLA_PRODUCT_VERSION=7.1
  REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
  REDHAT_SUPPORT_PRODUCT_VERSION="7.1"

Here the version ID is 7.1; different to CentOS.

Is this a bug or is it deliberate?

-- 

rgds
Stephen
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 License???

[John R Pierce]

On 4/1/2015 10:56 AM, David A. De Graaf wrote:

Is this a cute April Fool joke?
If not, WTF is going on?



hmm, I wasn't even watching the console of a C7 VM running under esxi, 
it rebooted in about 10 seconds to 7.1, no such EULA afaik.




--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Release 7 1503 includes samba-common.i686 (breaks multilib installs)

[Benjamin Ash]

Thanks - I filed http://bugs.centos.org/view.php?id=8370

-ben

On Wed, Apr 1, 2015 at 1:23 PM, Karanbir Singh  wrote:
> Hi,
>
> Can you file this as a bugreport on bugs.centos.org and we will work it
> asap.
>
> - KB
>
> On 04/01/2015 05:51 PM, Benjamin Ash wrote:
>> Hi,
>>
>> Unfortunately we are getting multilib issues with the latest release
>> of CentOS 7. It seems that samba-common.i686 conflicts with
>> samba-common.x86_64, and therefore Yum multilib support.
>>
>> Is this expected?
>>
>>
>> Thanks,
>> -ben
>>
>> Transaction check error:
>>   file /usr/bin/net conflicts between attempted installs of
>> samba-common-0:4.1.12-21.el7_1.i686 and
>> samba-common-0:4.1.12-21.el7_1.x86_64
>>   file /usr/bin/pdbedit conflicts between attempted installs of
>> samba-common-0:4.1.12-21.el7_1.i686 and
>> samba-common-0:4.1.12-21.el7_1.x86_64
>>   file /usr/bin/profiles conflicts between attempted installs of
>> samba-common-0:4.1.12-21.el7_1.i686 and
>> samba-common-0:4.1.12-21.el7_1.x86_64
>>   file /usr/bin/smbcontrol conflicts between attempted installs of
>> samba-common-0:4.1.12-21.el7_1.i686 and
>> samba-common-0:4.1.12-21.el7_1.x86_64
>>   file /usr/bin/testparm conflicts between attempted installs of
>> samba-common-0:4.1.12-21.el7_1.i686 and
>> samba-common-0:4.1.12-21.el7_1.x86_64
>>
>
>
> --
> Karanbir Singh
> +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
> GnuPG Key : http://www.karan.org/publickey.asc
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos



-- 
Benjamin Ash | Technical Manager - Intelerad
RHCE

+1-514-931-6222 ext. 7311 | b...@intelerad.com
Website  | Twitter
 | LinkedIn  |
 Blog 

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Centos 7 License???

[David A. De Graaf]

Today I did a yum upgrade to my kvm'ized Centos 7 test machine
(perhaps a bad day to do such a thing) and received new kernel
vmlinuz-3.10.0-229.1.2.el7.x86_64, among many other things. 
When I rebooted, I was asked to confirm (or renew, or some such)
my license.  My LICENSE ???

I was booting in text mode and the actions required were
a) unfamiliar, and b) hard to understand.

As I recall, I had to read the EULA - a worrisomely Microsoftian 
demand - and accept it.  Of course, the terms were pretty benign.
Then I had to continue.  I can't remember the exact language.
Of course, now when I reboot, all this cruft is gone.

Is this a cute April Fool joke?
If not, WTF is going on?

-- 
David A. De GraafDATIX, Inc.Hendersonville, NC
d...@datix.us www.datix.us


A: Because people read from top to bottom
Q: Why is top posting bad?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Thanks for 7.1

[Les Mikesell]

On Wed, Apr 1, 2015 at 12:43 PM, John R Pierce  wrote:
> On 4/1/2015 1:39 AM, Karanbir Singh wrote:
>>
>> is it possible that the mirror you are hitting isnt updated as yet ?
>
>
> 'probable' is more likely than 'possible'  :)

A 'yum clean all' made my systems work yesterday - probably just from
picking a different mirror on the next run.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Thanks for 7.1

[John R Pierce]

On 4/1/2015 1:39 AM, Karanbir Singh wrote:

is it possible that the mirror you are hitting isnt updated as yet ?


'probable' is more likely than 'possible'  :)

now its updating.

last night, on two different passes, it tried...

 * base: dallas.tx.mirror.xygenhosting.com
 * epel: linux.mirrors.es.net
 * extras: linux.mirrors.es.net
 * updates: dallas.tx.mirror.xygenhosting.com

and

 * base: mirror.pac-12.org
 * epel: linux.mirrors.es.net
 * extras: linux.mirrors.es.net
 * updates: mirror.oss.ou.edu

But, my real question was the part about whether I need to do anything 
after using CR to 'undo' that, and I guess the answer is, 'no'.   just 
now my system ...


Installed:
  kernel.x86_64 0:3.10.0-229.1.2.el7 kernel-devel.x86_64 
0:3.10.0-229.1.2.el7rdma.noarch 
0:7.1_3.17-5.el7


Updated:
  centos-logos.noarch 0:70.0.6-2.el7.centos centos-release.x86_64 
0:7-1.1503.el7.centos.2.8 compat-db-headers.noarch 0:4.7.25-28.el7  
compat-db47.x86_64 0:4.7.25-28.el7
  cronie.x86_64 0:1.4.11-13.el7 cronie-anacron.x86_64 
0:1.4.11-13.el7  flac-libs.x86_64 
0:1.3.0-5.el7_1  harfbuzz.x86_64 0:0.9.20-4.el7
  kernel-debug-devel.x86_64 0:3.10.0-229.1.2.el7 kernel-headers.x86_64 
0:3.10.0-229.1.2.el7 kernel-tools.x86_64 0:3.10.0-229.1.2.el7 
kernel-tools-libs.x86_64 0:3.10.0-229.1.2.el7
  libxml2.x86_64 0:2.9.1-5.el7_1.2 postgresql.x86_64 0:9.2.10-2.el7_1 
postgresql-contrib.x86_64 0:9.2.10-2.el7_1 postgresql-devel.x86_64 
0:9.2.10-2.el7_1
  postgresql-libs.x86_64 0:9.2.10-2.el7_1 postgresql-server.x86_64 
0:9.2.10-2.el7_1  setup.noarch 0:2.8.71-5.el7   
tzdata.noarch 0:2015b-1.el7
  tzdata-java.noarch 0:2015b-1.el7  xz.x86_64 
0:5.1.2-9alpha.el7   xz-libs.x86_64 0:5.1.2-9alpha.el7


Complete!



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] tc seems to have no effect on the NIC's

[Marcelo Ricardo Leitner]

On 01-04-2015 13:16, Boris Epstein wrote:

Hello all,

We have installed this network testing environment:

https://github.com/facebook/augmented-traffic-control

which seems pretty nice overall.

It allows you to artificially degrade your network performance by issuing
tc commands to directly affect your networking.

I have it set up on two CentOS 6 machines - one a Dell server, one a
VirtualBox VM. The tc syntax seems OK, it seems to all make sense - only it
seems to have no effect whatsoever on the actual network performance.

Hence the question: is there a known issue with tc? Am I perhaps missing
some kernel modules, or do I perhaps now have some kernel parameters set
correctly?

Any insight will be helpful.


Hi Boris,

Maybe it's just not matching your traffic and thus putting it in the 
main class, lets say.


You can check how it's going on with
tc -s qdisc show dev DEV
and
tc -s class show dev DEV
Both have some interestings stats that you can watch using watch -d and 
check through where your traffic is flowing.


If the numbers you want to are not changing, you're probably missing the 
tc filters for matching them.


  Marcelo

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Release 7 1503 includes samba-common.i686 (breaks multilib installs)

[Karanbir Singh]

Hi,

Can you file this as a bugreport on bugs.centos.org and we will work it
asap.

- KB

On 04/01/2015 05:51 PM, Benjamin Ash wrote:
> Hi,
> 
> Unfortunately we are getting multilib issues with the latest release
> of CentOS 7. It seems that samba-common.i686 conflicts with
> samba-common.x86_64, and therefore Yum multilib support.
> 
> Is this expected?
> 
> 
> Thanks,
> -ben
> 
> Transaction check error:
>   file /usr/bin/net conflicts between attempted installs of
> samba-common-0:4.1.12-21.el7_1.i686 and
> samba-common-0:4.1.12-21.el7_1.x86_64
>   file /usr/bin/pdbedit conflicts between attempted installs of
> samba-common-0:4.1.12-21.el7_1.i686 and
> samba-common-0:4.1.12-21.el7_1.x86_64
>   file /usr/bin/profiles conflicts between attempted installs of
> samba-common-0:4.1.12-21.el7_1.i686 and
> samba-common-0:4.1.12-21.el7_1.x86_64
>   file /usr/bin/smbcontrol conflicts between attempted installs of
> samba-common-0:4.1.12-21.el7_1.i686 and
> samba-common-0:4.1.12-21.el7_1.x86_64
>   file /usr/bin/testparm conflicts between attempted installs of
> samba-common-0:4.1.12-21.el7_1.i686 and
> samba-common-0:4.1.12-21.el7_1.x86_64
> 


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Release 7 1503 includes samba-common.i686 (breaks multilib installs)

[Benjamin Ash]

Hi,

Unfortunately we are getting multilib issues with the latest release
of CentOS 7. It seems that samba-common.i686 conflicts with
samba-common.x86_64, and therefore Yum multilib support.

Is this expected?


Thanks,
-ben

Transaction check error:
  file /usr/bin/net conflicts between attempted installs of
samba-common-0:4.1.12-21.el7_1.i686 and
samba-common-0:4.1.12-21.el7_1.x86_64
  file /usr/bin/pdbedit conflicts between attempted installs of
samba-common-0:4.1.12-21.el7_1.i686 and
samba-common-0:4.1.12-21.el7_1.x86_64
  file /usr/bin/profiles conflicts between attempted installs of
samba-common-0:4.1.12-21.el7_1.i686 and
samba-common-0:4.1.12-21.el7_1.x86_64
  file /usr/bin/smbcontrol conflicts between attempted installs of
samba-common-0:4.1.12-21.el7_1.i686 and
samba-common-0:4.1.12-21.el7_1.x86_64
  file /usr/bin/testparm conflicts between attempted installs of
samba-common-0:4.1.12-21.el7_1.i686 and
samba-common-0:4.1.12-21.el7_1.x86_64

-- 
Benjamin Ash | Technical Manager - Intelerad
RHCE

+1-514-931-6222 ext. 7311 | b...@intelerad.com
Website  | Twitter
 | LinkedIn  |
 Blog 

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Unexplained size difference with CentOS 7 (1503) -01 install media

[Greg Bailey]

In the process of updating my copy of the CentOS 7 (1503) -01 install 
media, I notice that it's ~70MB larger than the image that it's replacing:


$ rsync mirrors.kernel.org::centos/7.1.1503/isos/x86_64/*DVD*.iso

-rw-r--r--  4310695936 2015/03/31 17:05:50 CentOS-7-x86_64-DVD-1503-01.iso
-rw-r--r--  4236247040 2015/03/28 12:15:26 CentOS-7-x86_64-DVD-1503.iso

But when I compare sizes using "du" on the mounted ISO files, I can't 
see any discernible difference:


Original CentOS 7 (1503) DVD:

$ du -ks /centos7/*
1/centos7/CentOS_BuildTag
6148/centos7/EFI
1/centos7/EULA
18/centos7/GPL
79428/centos7/images
73378/centos7/isolinux
281423/centos7/LiveOS
3752743/centos7/Packages
12696/centos7/repodata
2/centos7/RPM-GPG-KEY-CentOS-7
2/centos7/RPM-GPG-KEY-CentOS-Testing-7
3/centos7/TRANS.TBL

Revised CentOS 7 (1503) -01 DVD with centos-release fix:

$ du -ks /centos7-01/*
1/centos7-01/CentOS_BuildTag
6148/centos7-01/EFI
1/centos7-01/EULA
18/centos7-01/GPL
79428/centos7-01/images
73378/centos7-01/isolinux
281423/centos7-01/LiveOS
3752745/centos7-01/Packages
12696/centos7-01/repodata
2/centos7-01/RPM-GPG-KEY-CentOS-7
2/centos7-01/RPM-GPG-KEY-CentOS-Testing-7
3/centos7-01/TRANS.TBL

Seems like a large delta in ISO size for not much of a change in 
content.   Any ideas?


-Greg

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Stephen Harris]

On Wed, Apr 01, 2015 at 06:09:01PM +0200, Andrew Holway wrote:
> In the UK we have a law which give you the right to remain silent; so as
> not to incriminate yourself. I think in the US its known as "taking the
> fifth".

The UK RIPA act requires you to hand over decryption keys upon presentation
of the correct paperwork.

-- 

rgds
Stephen
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Valeri Galtsev]

On Wed, April 1, 2015 11:09 am, Andrew Holway wrote:
>>
>> This is all interesting, but I've got one dumb question: why do you need
>> to decrypt it?
>>
>
> In the UK we have a law which give you the right to remain silent; so as
> not to incriminate yourself. I think in the US its known as "taking the
> fifth".

Indeed.

But I for one can deduce the answer, assuming the OP knows everything I
know or more (sorry for abbr.; Original Poster I had to say). Here is my
speculation:

One can easily replace root password hash in kickstart. The only scenarios
that that is not enough I can imagine are:

1. OP has to deal with machine kickstarted before and had no ability (or
wants to avoid it to leave no track that that is done) to boot the machine
in a single user mode and edit shadow file

2. OP was able to get kickstart file content (the hash actually), _has_ to
use it, but is not able to edit it (or editing is not an option due to
some other consideration)

3. This is somebody's else kickstart password, but I do exclude
immediately it as as a result one can imagine a [cyber]criminal action
here which I don't expect from anyone ;-)

That said, I just have to mention it once again. It is really advisable to
always change root password that came from kickstart file before even new
system goes live.

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] SEmodule dependency hell.

[James B. Byrne]

I want you all to see what I went through trying to simply reassign
(unsuccessfully) the context of a well-known port.

To the best of my ability to recall none of the packages mentioned
below are even installed on the host in question.  Why are these
dependices preventing me from removing a disused SELinux policy.

I have done exactly that, reassign port contexts, in the past without
encountering this situation.  So it has to be a recent development.  I
am not against SELinux.  We use it extensively.  But this is not
security it is simply BS.

It is stuff like this that causes people to say just turn selinux off
altogether.


semodule -r apache
libsepol.print_missing_requirements: awstats's global requirements
were not met: type/attribute httpd_log_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r awstats

semodule -r apache
libsepol.print_missing_requirements: bugzilla's global requirements
were not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r bugzilla

semodule -r apache
libsepol.print_missing_requirements: cobbler's global requirements
were not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r cobbler

semodule -r apache
libsepol.print_missing_requirements: collectd's global requirements
were not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r collectd

semodule -r apache
libsepol.print_missing_requirements: git's global requirements were
not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r git

semodule -r apache
libsepol.print_missing_requirements: gpg's global requirements were
not met: type/attribute httpd_sys_content_t (No such file or
directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r gpg

semodule -r apache
libsepol.print_missing_requirements: mediawiki's global requirements
were not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r mediawiki

semodule -r apache
libsepol.print_missing_requirements: munin's global requirements were
not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r munin

semodule -r apache
libsepol.print_missing_requirements: nagios's global requirements were
not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r nagios

semodule -r apache
libsepol.print_missing_requirements: w3c's global requirements were
not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r apache
libsepol.print_missing_requirements: webadm's global requirements were
not met: type/attribute httpd_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r webadm

semodule -r apache
libsepol.print_missing_requirements: webalizer's global requirements
were not met: type/attribute httpd_sys_content_t (No such file or
directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).
semodule:  Failed!

semodule -r webalizer

semodule -r apache
libsepol.context_from_record: type httpd_openshift_script_exec_t is
not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert
unconfined_u:object_r:httpd_openshift_script_exec_t:s0 to sid
invalid context unconfined_u:object_r:httpd_openshift_script_exec_t:s0
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule:  Failed!

semodule -R
[root@xnet241 ~]# semanage port -d -t http_port_t -p tcp 80
/usr/sbin/semanage: Port tcp/80 is defined in policy, cannot be deleted


-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
http://list

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Les Mikesell]

On Wed, Apr 1, 2015 at 6:25 AM, Karanbir Singh  wrote:
> On 04/01/2015 11:45 AM, Александр Кириллов wrote:
>>> This was discussed on the CentOS-Devel mailing list and approved by the
>>> CentOS Board. It is what we are using in the future.  I suggest you
>>> become familiar with it.
>>
>> Obviously naming conventions should provide for an easy upstream vendor
>> version reference?
>
> does /etc/centos-release-upstream provide you with that ?

Are you supposed to download an iso image, install it, then read that
file before you know which  upstream base minor number you got?In
the whole long thread where this naming was supposedly 'discussed', I
can't find a single user agreeing that dropping the minor number
reference out of the name  was a sane thing to do.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] tc seems to have no effect on the NIC's

[Boris Epstein]

Hello all,

We have installed this network testing environment:

https://github.com/facebook/augmented-traffic-control

which seems pretty nice overall.

It allows you to artificially degrade your network performance by issuing
tc commands to directly affect your networking.

I have it set up on two CentOS 6 machines - one a Dell server, one a
VirtualBox VM. The tc syntax seems OK, it seems to all make sense - only it
seems to have no effect whatsoever on the actual network performance.

Hence the question: is there a known issue with tc? Am I perhaps missing
some kernel modules, or do I perhaps now have some kernel parameters set
correctly?

Any insight will be helpful.

Thanks in advance,

Cheers,

Boris.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Andrew Holway]

>
> This is all interesting, but I've got one dumb question: why do you need
> to decrypt it?
>

In the UK we have a law which give you the right to remain silent; so as
not to incriminate yourself. I think in the US its known as "taking the
fifth".
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[m . roth]

Warren Young wrote:
> On Mar 30, 2015, at 11:08 PM, Jegadeesh Kumar  wrote:
>> # Root password
>> rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/
>> # System authorization information
>> auth  --useshadow  --passalgo=sha512
>
> Those two settings are inconsistent.  The $1 at the beginning of that
> crypt(3) string means it’s an MD5 password.
>
>> Is there any way to decry pt the password and get it as plain text.


This is all interesting, but I've got one dumb question: why do you need
to decrypt it?

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] SELinux on CentOS-6.6

[James B. Byrne]

I wish to reuse ports 80 and 443 for a different service.  When I try
to assign the port context for that service I get this:

/usr/sbin/semanage: Port tcp/80 already defined

When I try to delete the assigned context then I get this:

semanage port -d -t http_port_t -p tcp 80
/usr/sbin/semanage: Port tcp/80 is defined in policy, cannot be deleted

httpd is not installed on this host.  But looking at the port context
assignments I see this nonetheless:

semanage port -l | grep ^http_port_t
http_port_t tcp  80, 81, 443, 488, 8008, 8009, 8443, 9000

How do I rid myself of these artefacts and make the context
assignments that I wish?


-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Warren Young]

On Mar 30, 2015, at 11:37 PM, Eero Volotinen  wrote:
> 
> Well, you could bruteforce sha512 hashed password or use dictionary attack
> against it.

The sad thing is that dictionary attacks still work.  Just a few months ago on 
this very mailing list, we had a big battle over whether the default password 
rules should be tightened down to preclude them.  

> No realistic way to encrypt hashed password.

Of course you mean “decrypt,” but there’s a bigger mistake in that statement.

Simply hashing the password *does* allow for a realistic attack: rainbow 
tables.  This uses a large array of computers to calculate the hash for every 
entry in a given set of passwords.

Check out this list of freely-downloadable rainbow tables:

  http://project-rainbowcrack.com/table.htm

It tells you that if you’ve been using a 10-character all-lowercase password 
with possibly a digit or two, it can probably be cracked instantly by referring 
to this rainbow table.  *If*, that is, it was stored in a password database 
that simply hashes the password to protect it.

The single simplest way to defeat rainbow tables is by salting the password, 
which Unix systems have done since approximately forever.[1]  Linux copied that 
practice from the beginning.

The reason rainbow tables exist is that there are still password systems today 
that ignore this 37-year-old lesson.  A lot of web sites store their passwords 
this way, which is why the standard advice is to never reuse the same password 
at more than one site, even if they claim to “encrypt” your password.

Once you step beyond MD5 passwords on CentOS to SHA-256 or SHA-512, you have 
the option of using a random number of hashing rounds, greatly increasing the 
difficulty of producing a rainbow table and the space required to hold it:

- SHA-512 takes about 3x the space of SHA-1, which produced about 2 TiB of 
tables on the page I linked above.

- The salt is 12 bits of randomness, multiplying the number of required tables 
by 4,096.

- The man pages are unclear, but I believe the default range of random rounds 
in CentOS 6 & 7 is 1,000 to 5,000.  If, so, this multiplies the resource 
requirements again by 4,000.[2]

All together, the storage space is about 94 EiB, which is approximately equal 
to the amount of information interchanged across the world’s telecommunications 
networks in a year.[3]  The difficulty of cracking a single SHA-512 password as 
done on CentOS 7 is roughly as difficult as building a second Internet, just as 
big as the first, without reusing any of the current Internet resources.

Given that the current Internet takes a few billion people to run, mostly in 
their spare time, you probably need several million full-time staffers to run 
your CrackNet.  

Most of those staffers will be spending their time just replacing failed 
components.  Given that the MTBF on the electromechanical components of the 
CrackNet is only in the low millions of hours, having billions of them means 
you can expect a continuous stream of failed hard drives and fans.

If you’re still worried, you can edit /etc/libuser.conf, increasing 
hash_rounds_max.  It can go up to 999,999,999, which means you can increase the 
CrackNet scenario’s difficulty by up to 250,000 times.

If you find yourself in control of a quarter million CrackNets, you are 
probably a superintelligent energy form living in the post-Singularity world, 
by which point all this worry about password security will have become a rather 
low-priority concern.




--

[1] This 1978 paper by Ken Thompson and Robert Morris talks about salted 
passwords in Unix: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps

As far as I can tell, this first appeared in UNIX V7 (1979).


[2] If my understanding of this point is wrong, the OS can be configured to do 
this.

While you’re thinking about this, you could changing the default range to 5,000 
to 10,000, for example, which would break even the ridiculous CrackNet scenario 
at the cost of only ~4x longer password verification time, on average.  It 
would probably still run in under a second, which is fast enough for 
human-interactive tests.


[3] Source: http://en.wikipedia.org/wiki/Petabyte
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Lamar Owen]

On 03/31/2015 11:11 PM, Peter wrote:
Can you please point me to the centos-devel thread that discussed 
changing the iso naming convention from CentOS-7.1-1503-x86_64-DVD.iso 
to CentOS-7-x86_64-DVD-1503.iso? I must have missed it because I saw 
no mention of this change until today.
The first thread along these lines starts at 
http://lists.centos.org/pipermail/centos-devel/2014-June/010444.html


It is a long thread, as you should know, since you participated in it.

The key post in the thread, in my opinion, is at 
http://lists.centos.org/pipermail/centos-devel/2014-June/010944.html


My takeaway is that the ISO name for 7.1406 was an aberration, and that 
this is the new paradigm going forward.  But I'll also reserve the right 
to be wrong.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Thanks for 7.1

[Lamar Owen]

On 04/01/2015 04:39 AM, Karanbir Singh wrote:
is it possible that the mirror you are hitting isnt updated as yet ? 


I like John updated with CR, but subsequent updates didn't pull in the 
newer /etc/centos-release.  Prior to a 'yum clean all' a 'yum list 
updates' as of ten minutes ago listed nothing; after doing a 'yum clean 
all' there were several updates, which I'm doing now.


Of course, once I did the 'yum clean all' I lost the information on 
which mirrors I had been using; John may still have that information.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] mirrors still catching up and -01.iso images?

[Stuart Barkley]

I now see an announcement on the centos-announce list which explains
most/all of what I was seeing last night.

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
--  Daniel Boone
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] mirrors still catching up and -01.iso images?

[Stuart Barkley]

I'm watching a couple of mirrors catch up with the 7.1 release and am
noticing some churn on the .iso images.

It appears that new -01.iso versions are coming downstream while some
of the mirrors apparently were getting different .iso images.  The
-01.iso versions look to be significantly larger than the previous
non-01.iso versions (the -Minimal .iso appears to have gone from 560M
to 630M for -01.iso).

I'm not downloading the larger .iso image so don't know the actual
content, but the md5/sha files also changed and some of the mirrored
-01.iso versions appear to have different sizes (actually from the
timestamps it looks like the non-01.iso versions might have been
renamed -01.iso before being replaced with newer content).

What is the difference between the non-01.iso versions and the -01.iso
versions?  Is this what we can expect with the monthly rebuilds?

For tracability reasons, I don't like seeing different .iso images at
different times.  We really need to see consistent content on the
distribution mirrors.

Some of this may still be churn and one mirror may have run out of
disk space (or otherwise be waiting for manual intervention).

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
--  Daniel Boone
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] kernel Panic on desktop

[James B. Byrne]

I arrived at work this morning to find that my desktop unit
(CentOS-6.6 KVM) halted with a kernel panic.  I am not conversant with
any way to save the console display in this case and there was rather
a lot of text.  I jotted down a few notes and power-cycled the unit to
restart.  which it did and I am using now to compose this message.

The few notes that I manually copied, subject to transcription errors,
were:

 ? pci-configure - slot 0x365.0x420
. . .
 pic (ed. note: transcription error? maybe pci?)
. . .
 pciehpd - Tainted: G   D  2.6.32-504.12.2.el6.x86_64 #1
 panic+0x17/0x16f
. . .
 kvm 2998 cpu0 disabled: perfctr wrmsr 0xc1 data 0xabcd

1. Is there any way to get the entire console display following a
panic as a text file?

2. I take that this points to a hardware issue of some sort.  Any
suggestions as to where I look?

The system has two NICs but one is disused and has no cable. 
Following a update last year I began receiving console messages
complaining about this state but ignored them.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] opendkim-2.9.0

[James B. Byrne]

On Tue, March 31, 2015 16:18, Frank Cox wrote:
> On Tue, 31 Mar 2015 16:11:38 -0400
> James B. Byrne wrote:
>
>> Does anyone have any idea what has happened and why I might be
>> getting that message?
>
> I don't use that but have you checked to see if you now have a
> "rpmsave" file left after installing the update?  If so, that's your
> old configuration and you might need to re-write the new configuration
> file to incorporate your previous customization.
>

Yes that was the problem.  The OpenDKIM maintainers deprecated a
configuration option (SenderHeaders) that we were using so the
opendkim service would not restart.  So there was nothing listening at
port 8891. Removing the optin fixed the problem.

I can find no discussion of why this option was removed and the
OpenDKIM readme (http://www.opendkim.org/opendkim-README) still makes
reference to it as the preferred way of handling mailing lists.  Go
figure.

B.T.W.
Redhat has apparently 'fixed' (I think) Mailman to deal with the
Yahoo/AOL - DMARC problems. But only in RHEL5 (so far). As they have
moved all discussion of the bug behind a paywall I can no longer
follow developments and so cannot be sure.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[me]

On Wed, 1 Apr 2015, Karanbir Singh wrote:


On 04/01/2015 11:45 AM, Александр Кириллов wrote:

This was discussed on the CentOS-Devel mailing list and approved by the
CentOS Board. It is what we are using in the future.  I suggest you
become familiar with it.


Obviously naming conventions should provide for an easy upstream vendor
version reference?


does /etc/centos-release-upstream provide you with that ?


/etc/centos-release-upstream is not useful when looking at an iso name.

With 7.0 the iso name was CentOS-7.0-1406-x86_64-DVD.iso. With 7.1 the
iso name is CentOS-7-x86_64-DVD-1503-01.iso. Since you dropped the minor
version in the iso name and assuming that you are not going to put it
back in the future, going forward I will need a chart to figure out what
upstream version an iso corresponds to.

How is that better?

Regards,

--
Tom m...@tdiehl.org Spamtrap address
me...@tdiehl.org___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to decrypt rootpassword form kickstart file

[Warren Young]

On Mar 30, 2015, at 11:08 PM, Jegadeesh Kumar  wrote:
> # Root password
> rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/
> # System authorization information
> auth  --useshadow  --passalgo=sha512

Those two settings are inconsistent.  The $1 at the beginning of that crypt(3) 
string means it’s an MD5 password.

> Is there any way to decry pt the password and get it as plain text.

Do you have any idea how long the original password is, and what “alphabet” it 
uses?  (i.e. Lowercase only, or mixed case?  Does it also include numbers and 
symbols?)

If so, this page will give you some idea of what it will take to crack that 
password:

   https://www.grc.com/haystack.htm

You are probably looking at something like the middle scenario, “offline fast 
attack,” since you probably don’t have a massive server farm to attack this 
with, and that page was probably written with MD5 attacks in mind, given that 
it was created in 2011.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Phelps, Matthew]

On Wed, Apr 1, 2015 at 8:23 AM, Александр Кириллов 
wrote:

> Karanbir Singh писал 2015-04-01 14:25:
>
>> On 04/01/2015 11:45 AM, Александр Кириллов wrote:
>>
>>> This was discussed on the CentOS-Devel mailing list and approved by the
 CentOS Board. It is what we are using in the future.  I suggest you
 become familiar with it.

>>>
>>> Obviously naming conventions should provide for an easy upstream vendor
>>> version reference?
>>>
>>
>> does /etc/centos-release-upstream provide you with that ?
>>
>
> There's nothing of the sort in 7.0.1406.
> Ideally I'd like to see 7.1 in each and every rpm or iso name related to
> the point release.
> I'm not going to flame over something done and buried but sometimes the
> decisions made by rational people are just stunningly surprising.
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


It's not surprising, it's stunningly annoying.

Those of us who manage large installations of CentOS aren't involved in the
development list or the board (we don't have time).

I urge the CentOS board to reconsider such a large departure from upstream.
And I urge them to reach out far beyond the devel-list for opinions as that
is a distinct, and quite separate, base of thought.

And, it's not just a matter of "calling it 7.1, or whatever you like." We
have many scripts and operations based on determining the "version number"
and if it is inconsistent with RHEL, and logic for that matter, it is more
work for those who don't need it.

Yes, I'm whining. I get that. But I think I'm not alone.



-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphe...@cfa.harvard.edu, http://www.cfa.harvard.edu
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Александр Кириллов]

Karanbir Singh писал 2015-04-01 14:25:

On 04/01/2015 11:45 AM, Александр Кириллов wrote:
This was discussed on the CentOS-Devel mailing list and approved by 
the

CentOS Board. It is what we are using in the future.  I suggest you
become familiar with it.


Obviously naming conventions should provide for an easy upstream 
vendor

version reference?


does /etc/centos-release-upstream provide you with that ?


There's nothing of the sort in 7.0.1406.
Ideally I'd like to see 7.1 in each and every rpm or iso name related to 
the point release.
I'm not going to flame over something done and buried but sometimes the 
decisions made by rational people are just stunningly surprising.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Karanbir Singh]

On 04/01/2015 11:45 AM, Александр Кириллов wrote:
>> This was discussed on the CentOS-Devel mailing list and approved by the
>> CentOS Board. It is what we are using in the future.  I suggest you
>> become familiar with it.
> 
> Obviously naming conventions should provide for an easy upstream vendor
> version reference?

does /etc/centos-release-upstream provide you with that ?


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Karanbir Singh]

On 04/01/2015 10:07 AM, Ron Yorston wrote:
> Johnny Hughes wrote:
>> This was discussed on the CentOS-Devel mailing list and approved by the
>> CentOS Board.
> 
> Yes, it was discussed at great length on centos-devel.  The core
> developers proposed a date-based versioning system which met with
> much opposition.  I certainly wasn't convinced by their arguments.
> 
>> It is what we are using in the future.  I suggest you become familiar
>> with it.
> 
> You can call it what you like.  I'll still call it CentOS 7.1.

as you should - the important thing is that we all know ( where 'we' is
the community at large, the consumers and the SIGs ) all have a frame of
reference that maps to the same target; different people have different
goal posts - and if your's involves a 7.1, please use it.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Александр Кириллов]

This was discussed on the CentOS-Devel mailing list and approved by the
CentOS Board. It is what we are using in the future.  I suggest you
become familiar with it.


Obviously naming conventions should provide for an easy upstream vendor 
version reference?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Ron Yorston]

Johnny Hughes wrote:
>This was discussed on the CentOS-Devel mailing list and approved by the
>CentOS Board.

Yes, it was discussed at great length on centos-devel.  The core
developers proposed a date-based versioning system which met with
much opposition.  I certainly wasn't convinced by their arguments.

>It is what we are using in the future.  I suggest you become familiar
>with it.

You can call it what you like.  I'll still call it CentOS 7.1.

Ron
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Thanks for 7.1

[Karanbir Singh]

On 01/04/15 06:56, John R Pierce wrote:
> On 3/31/2015 5:25 PM, Nux! wrote:
>> Just wanted to say "Thanks!" to the CentOS team for their efforts to
>> put out a 7.1 release.
> 
> 
> so I updated my c7 dev systems last night with CR...  do I need to do
> anything special to get it to clean update ?   yum update isn't offering
> me anything newer and centos-release still says its 1406
> 
> 
> 

is it possible that the mirror you are hitting isnt updated as yet ?

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

[Alain Péan]

Le 31/03/2015 23:24, Alain Péan a écrit :
It seems that also the redhat-release file has changed.Previously, it 
was :

[root@centos7 ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)

Now it is :
[root@centos-test ~]# cat /etc/redhat-release
Derived from Red Hat Enterprise Linux 7.1 (Source)

It is also my opinion that the name CentOS-7-x86_64-DVD-1503.iso is 
rather confusing, it is not immediately evident that it is release 7.1.
I would have prefered the name CentOS-7.1-1503-x86_64-DVD.iso, 
following the previous name convention.


After Karanbir answer, the redhat-release file has indeed changed after 
a new 'yum update'. It it now :

[root@centos-test ~]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

Thanks. It could indeed impact such tools as Dell OMSA ant a lot others 
I think.


Alain


--
Administrateur Système/Réseau
Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20)
Centre de Recherche Alcatel Data IV - Marcoussis
route de Nozay - 91460 Marcoussis
Tel : 01-69-63-61-34

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos