[CentOS] why does "rescue" mode bring me to runlevel 5 (multi-user target)?

[Robert P. J. Day]

  finishing a week of teaching a comptia linux+ class off of centos
7.4 and wanted to demo how to boot to "rescue" mode, so i rebooted,
selected "rescue" mode at grub menu, which still booted to full
multiuser, graphical mode. what am i doing wrong? or is this a dumb
question?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [CentOS] Going back to a minimal system : strange problem

[Gordon Messmer]

On 02/26/2018 09:25 AM, Nicolas Kovacs wrote:

I wonder if it might work to use a yum transaction, in which you
first remove everything (which avoids the need for the list
entirely), then adds the minimal package set, and then commits the
transaction...

I only have a very vague notion of yum transactions, so I'll look into
that and report back.



My idea was:

   # yum shell
> transaction
> remove *
   Skipping the running kernel: kernel-3.10.0-693.11.1.el7.x86_64
> install @core
> run

...but that doesn't work.  First, because it complains that @core has no 
packages to install, but second and more importantly, it appears that 
even if you get the package selection right it will remove and reinstall 
the packages.  I'm not positive that'll break, but offhand, it doesn't 
look like the transaction would have been a workable solution.  You 
know, in case you were curious.  :)


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

Re: [CentOS] RADIUS

[Gordon Messmer]

On 03/01/2018 09:26 AM, hw wrote:
I was asking for documentation telling me how RADIUS can be used, not 
only

that it can be used.


RADIUS is a backend component of 802.1x and WPA2 Enterprise.  You appear 
to be looking for information on how to use those two.  If you look for 
documentation on those, you should be able to find what you're looking for.



The task is to provide wireless coverage for employees and customers on
company premises.  It is desirable to be able to keep track of customers,
as in knowing where exactly on the premises they currently are (within
like 3--5 feet, which is apparently tough), and simpler things like 
knowing

how long they stay and if they have been on the premises before.


You probably want to capture the WAP logs.  Their location will be best 
correlated with the specific WAP they connect to, assuming you have 
multiple.  The client MAC address will be your best indication of 
whether or not they've been there before.



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

Re: [CentOS] RADIUS

[Gordon Messmer]

On 03/01/2018 03:06 AM, hw wrote:


It is illogical to lump all network access together into a single 
category.

...
If your device can communicate with a switch, even for the purpose of 
authenticating, then it has network access.


The device has access to the switch which, depending on what answer to an
authentication request it gets from a RADIUS server, decides if and 
how it

lets the device access the network.


You're still lumping networks into a single category.

Not "the" network, but "a" network.

Unauthenticated clients are, by definition connected to A network 
consisting of the device and the switch.  They might also be connected 
to a network consisting of the device, a switch, and a TFTP server that 
provides the boot image to the client.  And since there is nothing else 
on that network, other than a read-only TFTP server that your devices 
require in order to boot, it's difficult to understand why you think 
there is a security risk here.


Security is the process of restricting access to a resource to only the 
devices and persons that require it.  If your devices require a boot 
image before they can authenticate, then restricting their access to 
that resource can no longer be described as "security."


Where do your hypothetical customers in a store get the user 
credentials that you want to authenticate via RADIUS?


They might get it from employees of the store or read it from signs
inside the store, perhaps depending on what kind of access rights they
are supposed to have.


If you're sharing passwords, then you don't need RADIUS.  Set up 
separate SSIDs that are attached to VLANs with appropriate access 
levels, and continue using WPA2 Personal.  Using RADIUS will be no 
more secure than that.  It's not magic.


Right, but what about keeping track of customers?  Apparently RADIUS 
has some

accounting features, and it might be an advantage to use those.


It does, but you will get exactly the same information using WPA2 
Personal that you will from WPA2 Enterprise and RADIUS.  "A client 
connected to the WAP at such and such time.  It disconnected at such and 
such time."


If you're sharing passwords, RADIUS is the most complex way to get the 
information.  You can get the same info by simply logging WAP events to 
a log server.



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

Re: [CentOS] Mirror Problem

[Stephen John Smoogen]

On 16 February 2018 at 14:20, Stephen John Smoogen  wrote:
> On 16 February 2018 at 08:36, Günther J. Niederwimmer  
> wrote:
>> Hello,
>> I have thousands of this messages on my servers ??
>>
>> Is this a Problem on my site or is the infrastructure broken??
>> /etc/cron.hourly/0yum-hourly.cron:
>>
>> Could not get metalink https://mirrors.fedoraproject.org/metalink?
>> repo=epel-7=x86_64 error was
>> 14: HTTPS Error 503 - Service Unavailable
>>
>> Thanks for a answer,
>>
>
> Hello, from the Fedora side of Infrastructure. We have been trying to
> get the 503 error rate down in the last six months and thought we had
> licked it with recent changes. We had moved down the error rate to
> 80,000 bad requests per day out of 13.5 million total ones which
> actually is a creep up from what we had last month. Most of the
> requests every day happen in the time frame of XX:00 -> XX:15 of every
> hour. Every proxy seems to give about 100 per day but 2 proxies seem
> to have had docker problems and have been each contributing 32,000 to
> 38,000 503's.
>
> We did find an error in the docker restart script which hopefully will
> drop this further. We are still evaluating why just those 2 proxies
> have so many more and will let you know what is found.
>
> Thank you for your patience.
>

To follow up we have cut the number of 503's down to 1200 per 13.5
million  per day. If you are still seeing problems with EPEL updates
please let us know with a time stamp and ip address of when they are
occurring. I am trying to track down if we have a problem with
specific proxies or times.



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-docs] Introduction

[Bruce Howells]

Following the Contribute directions, I'm BruceHowells.

I'd like to contribute to the OpenShift page, as I'm trying to work through
bringing up OpenShift on CentOS and have found an error in the
documentation (a reference to "yum install openshift" rather than
centos-release-openshift-origin) that I'd like to correct.

I also would like to extend the existing content.
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] RADIUS

[Chris Adams]

Once upon a time, hw  said:
> The task is to provide wireless coverage for employees and customers on
> company premises.  It is desirable to be able to keep track of customers,
> as in knowing where exactly on the premises they currently are (within
> like 3--5 feet, which is apparently tough), and simpler things like knowing
> how long they stay and if they have been on the premises before.  To avoid
> legal issues, it is probably advisable that customers need to agree to
> some sort of terms of usage.

What you are talking about requires very specialized wifi setups, which
AFAIK no freely-available tools implement.  You need to be talking to
enterprise wifi hardware vendors to get that kind of thing.

RADIUS is an AAA (Authentication, Authorization, and Accounting)
protocol.  It might be one small tool used in authorization, like
letting employees on the network, but that would be up to the wifi
vendor's controller system (some can use RADIUS, some can use AD, some
use their own systems, etc.).

-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] RADIUS

[Bruce Ferrell]

On 3/1/18 10:02 AM, Pete Biggs wrote:

What are your constraints? [AKA what have you been told to do.]

The task is to provide wireless coverage for employees and customers on
company premises.  It is desirable to be able to keep track of customers,
as in knowing where exactly on the premises they currently are (within
like 3--5 feet, which is apparently tough),

Tough? I would say basically impossible. The only way of getting that
sort of accuracy is to either have lots of pico cells so you know which
AP a device is connected to, or be able to triangulate. WiFi has a
reasonable range and devices like to hang on to an AP for as long as
possible, even if they can pass off on to a closer more powerful one.

I know retailers are looking at targeting customers via their location,
but I think that currently needs the co-operation of the customer's
device via a downloaded app.
There ARE companies that specialize in this type of thing.  It's really 
NOT a quicky-homebrew thing... Especially if one is staring with "tell 
me how to use  AAA protocol".

  and simpler things like knowing
how long they stay and if they have been on the premises before.

I can see now why you wanted to stop customers/employees from using
their 4G connection.
One thing to keep in mind if this is in the US... Blocking cellular 
bands (and publicly accessible radio in general) is grossly illegal and 
a serious felony.
Marriott corporation tried it with WiFi and got smacked with a VERY 
large fine and I heard that some of the licensed radio engineers 
involved were also personally fined... They should have known better.


The commonly used technique is Bluetooth beacons... But the victims (er 
customers) HAVE to co operate.



That is what using RADIUS apparently leads to when you have devices using
PXE boot.  Maybe they need to be considered as a security risk and be
replaced.

You mentioned X2Go and that your PXE booting clients used it. I know
X2Go and the client is a standalone app that uses ssh to login to the
server to initiate a remote desktop type environment.  There's nothing
in X2Go per se that requires a persistent network connection before
they connect. So, am I right in assuming that your PXE clients are
actually diskless machines that get all of their environment from the
network?

P.

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

Re: [CentOS] RADIUS

[Pete Biggs]

> > What do you want?
> 
> I was asking for documentation telling me how RADIUS can be used, not only
> that it can be used.

RADIUS is just an authentication (plus a bit more) protocol - what you
are asking is like asking how LDAP can be used. Usually it's treated
like a magic black box by applications in that one of the configuration
options is to "use a RADIUS server" and then you just configure the
necessary information in the client so it talks to the correct box. The
reason RADIUS is used rather than some other authentication protocol is
that it is designed to be used in a network authentication role.

Rather than focussing on the RADIUS aspect, you would probably be
better looking at the configuration and technology around how you want
the network to operate. The way the RADIUS server is used will be
obvious once you've sorted that out.

> 
> > What are your constraints? [AKA what have you been told to do.]
> 
> The task is to provide wireless coverage for employees and customers on
> company premises.  It is desirable to be able to keep track of customers,
> as in knowing where exactly on the premises they currently are (within
> like 3--5 feet, which is apparently tough),

Tough? I would say basically impossible. The only way of getting that
sort of accuracy is to either have lots of pico cells so you know which
AP a device is connected to, or be able to triangulate. WiFi has a
reasonable range and devices like to hang on to an AP for as long as
possible, even if they can pass off on to a closer more powerful one.

I know retailers are looking at targeting customers via their location,
but I think that currently needs the co-operation of the customer's
device via a downloaded app.

>  and simpler things like knowing
> how long they stay and if they have been on the premises before.

I can see now why you wanted to stop customers/employees from using
their 4G connection.

> 
> That is what using RADIUS apparently leads to when you have devices using
> PXE boot.  Maybe they need to be considered as a security risk and be
> replaced.

You mentioned X2Go and that your PXE booting clients used it. I know
X2Go and the client is a standalone app that uses ssh to login to the
server to initiate a remote desktop type environment.  There's nothing
in X2Go per se that requires a persistent network connection before
they connect. So, am I right in assuming that your PXE clients are
actually diskless machines that get all of their environment from the
network? 

P.

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

Re: [CentOS] RADIUS

[Stephen John Smoogen]

On 1 March 2018 at 12:26, hw  wrote:
> Stephen John Smoogen wrote:
>>
>> On 1 March 2018 at 08:42, hw  wrote:
>>
>>>
>>> I didn´t say I want that, and I don´t know yet what I want.  A captive
>>> portal may
>>> be nice, but I haven´t found a way to set one up yet, and I don´t have an
>>> access
>>> point controller which would provide one, so I can´t tell if that´s the
>>> right
>>> solution.
>>>
>>
>> This is the problem with this entire thread in a nutshell. You don't
>> know what you want but what you have articulated at various points is
>> that you do know what you want. You then state something that won't
>> work because of some factor or another. People then correct you on
>> that, and you then get hostile because you were just thinking out loud
>> but no one knew that. Thinking out loud works ok in real life because
>> we give special queues like looking abstractly or being able to say
>> "Oh no I am just thinking out loud" right away. Instead in email none
>> of that happens and people get more and more hostile and angry
>> thinking the other side is trying to make them do completely opposite.
>>
>> Let us try starting over. You may have answered these in other places,
>> but people need to see them in one place at one time versus trying to
>> look through cache of other emails.
>>
>> What do you want?
>
>
> I was asking for documentation telling me how RADIUS can be used, not only
> that it can be used.
>
>> What are your constraints? [AKA what have you been told to do.]
>
>
> The task is to provide wireless coverage for employees and customers on
> company premises.  It is desirable to be able to keep track of customers,
> as in knowing where exactly on the premises they currently are (within
> like 3--5 feet, which is apparently tough), and simpler things like knowing
> how long they stay and if they have been on the premises before.  To avoid
> legal issues, it is probably advisable that customers need to agree to
> some sort of terms of usage.
>

Oh yeah. Who ever gave you those marching orders needs to talk with
all kinds of lawyers... even researching for it might be problematic
in some countries due to a multitude of laws. You are walking out of
setting up a wireless environment into full-scale surveillance.

That said, what you are looking for is not going to be accomplished
with simple radius without a large amount of development. It is also
going to need a lot of wireless sensors running at different
frequencies through out the building. Most of that is done usually
with special commercial hardware/software and falls outside of scope
of this list by a mile.

RADIUS may be something that is done with all of this but only far way
back in the chain of tools needed. It might be something that the
specialized hardware, scanners, sensors, etc might tie into if they
don't have their own specialized tool. Worrying about it before those
are researched, etc is to use an English idiom: putting the cart
before the horse.

> It is desirable to be able to know where employees currently are, though
> it doesn´t neeed to be as precise.
>
>> When do you need it?
>
>
> There´s no given time frame; it´s as soon as possible and preferably
> this year.
>
> It is necessary to (re-)do the entire network infrastructure before wireless
> coverage can be achieved, one of the reasons being that it is currently
> impossible to use VLANs all over the place.
>
>> What is the environment that it is to run in?
>
>
> a shopping area
>
> Some of the wireless access points may need to take part in what is
> apparently called a mesh to be able to supply remote parts of the premises.
>
>> What research have you done (with references)?
>
>
> I searched for documenation about how to actually use RADIUS and didn´t
> find any.  I´ve asked for pointers to such documentation here.
> I´ve read the RADUIS admin guide.  I´ve done a test setup by installing
> RADIUS and configuring a switch to use it to authenticate users logging
> into the switch via ssh and found it works fine.  I have set up a couple
> access points in a test setup which currently provide wireless access for
> employees and wireless internet access for customers around some points
> of the premises.  I found out what a captive portal is.
>
>> Then people will have a better ability to answer:
>> What have others done to meet those needs?
>> How have they implemented it?
>>
>> Then ask
>> What other things do you need for me to help?
>>
>> People can then ask questions about things you didn't fully explain.
>> This is helpful because going from the previous emails your phrasing
>> made it sound like you needed unknown people to not be able to get
>> onto the network until they were authenticated, but authentication
>> requires them to be on a network, but you can't allow them to be on
>> any network until they are authenticated. That may not be what you
>> mean (on the other hand, I have had that conundrum given to me at a
>> job and 

Re: [CentOS] RADIUS

[hw]

Stephen John Smoogen wrote:

On 1 March 2018 at 08:42, hw  wrote:



I didn´t say I want that, and I don´t know yet what I want.  A captive
portal may
be nice, but I haven´t found a way to set one up yet, and I don´t have an
access
point controller which would provide one, so I can´t tell if that´s the
right
solution.



This is the problem with this entire thread in a nutshell. You don't
know what you want but what you have articulated at various points is
that you do know what you want. You then state something that won't
work because of some factor or another. People then correct you on
that, and you then get hostile because you were just thinking out loud
but no one knew that. Thinking out loud works ok in real life because
we give special queues like looking abstractly or being able to say
"Oh no I am just thinking out loud" right away. Instead in email none
of that happens and people get more and more hostile and angry
thinking the other side is trying to make them do completely opposite.

Let us try starting over. You may have answered these in other places,
but people need to see them in one place at one time versus trying to
look through cache of other emails.

What do you want?


I was asking for documentation telling me how RADIUS can be used, not only
that it can be used.


What are your constraints? [AKA what have you been told to do.]


The task is to provide wireless coverage for employees and customers on
company premises.  It is desirable to be able to keep track of customers,
as in knowing where exactly on the premises they currently are (within
like 3--5 feet, which is apparently tough), and simpler things like knowing
how long they stay and if they have been on the premises before.  To avoid
legal issues, it is probably advisable that customers need to agree to
some sort of terms of usage.

It is desirable to be able to know where employees currently are, though
it doesn´t neeed to be as precise.


When do you need it?


There´s no given time frame; it´s as soon as possible and preferably
this year.

It is necessary to (re-)do the entire network infrastructure before wireless
coverage can be achieved, one of the reasons being that it is currently
impossible to use VLANs all over the place.


What is the environment that it is to run in?


a shopping area

Some of the wireless access points may need to take part in what is
apparently called a mesh to be able to supply remote parts of the premises.


What research have you done (with references)?


I searched for documenation about how to actually use RADIUS and didn´t
find any.  I´ve asked for pointers to such documentation here.
I´ve read the RADUIS admin guide.  I´ve done a test setup by installing
RADIUS and configuring a switch to use it to authenticate users logging
into the switch via ssh and found it works fine.  I have set up a couple
access points in a test setup which currently provide wireless access for
employees and wireless internet access for customers around some points
of the premises.  I found out what a captive portal is.


Then people will have a better ability to answer:
What have others done to meet those needs?
How have they implemented it?

Then ask
What other things do you need for me to help?

People can then ask questions about things you didn't fully explain.
This is helpful because going from the previous emails your phrasing
made it sound like you needed unknown people to not be able to get
onto the network until they were authenticated, but authentication
requires them to be on a network, but you can't allow them to be on
any network until they are authenticated. That may not be what you
mean (on the other hand, I have had that conundrum given to me at a
job and we had to spend 3 months convincing the boss(es) that was
impossible with the tools we had (and probably impossible without)).


That is what using RADIUS apparently leads to when you have devices using
PXE boot.  Maybe they need to be considered as a security risk and be
replaced.

Unauthenticated people are easier to handle because people can provide
credentials for authentication without PXE booting them first and do not
access the network without a device (unless they mess with the very network
hardware, using cables to create loops or accidentially cutting them or
unplugging them or whatever --- people do all kinds of things, with
authentication and without ...).

Devices with network access are much more dangerous than unauthenticated
people because such devices could be used by such people to also gain network
access, or they could try to have bad effects on the network.

So everthing is dangerous, authenticated or not.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] RADIUS

[Stephen John Smoogen]

On 1 March 2018 at 08:42, hw  wrote:

>
> I didn´t say I want that, and I don´t know yet what I want.  A captive
> portal may
> be nice, but I haven´t found a way to set one up yet, and I don´t have an
> access
> point controller which would provide one, so I can´t tell if that´s the
> right
> solution.
>

This is the problem with this entire thread in a nutshell. You don't
know what you want but what you have articulated at various points is
that you do know what you want. You then state something that won't
work because of some factor or another. People then correct you on
that, and you then get hostile because you were just thinking out loud
but no one knew that. Thinking out loud works ok in real life because
we give special queues like looking abstractly or being able to say
"Oh no I am just thinking out loud" right away. Instead in email none
of that happens and people get more and more hostile and angry
thinking the other side is trying to make them do completely opposite.

Let us try starting over. You may have answered these in other places,
but people need to see them in one place at one time versus trying to
look through cache of other emails.

What do you want?
What are your constraints? [AKA what have you been told to do.]
When do you need it?
What is the environment that it is to run in?
What research have you done (with references)?

Then people will have a better ability to answer:
What have others done to meet those needs?
How have they implemented it?

Then ask
What other things do you need for me to help?

People can then ask questions about things you didn't fully explain.
This is helpful because going from the previous emails your phrasing
made it sound like you needed unknown people to not be able to get
onto the network until they were authenticated, but authentication
requires them to be on a network, but you can't allow them to be on
any network until they are authenticated. That may not be what you
mean (on the other hand, I have had that conundrum given to me at a
job and we had to spend 3 months convincing the boss(es) that was
impossible with the tools we had (and probably impossible without)).


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



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] RADIUS

[hw]

John Hodrien wrote:

This is really nothing to do with CentOS anymore, if it ever was.


right


On Thu, 1 Mar 2018, hw wrote:


If PXE boot is not possible because it would require to allow network access
to unauthorized devices, or if it is not reasonably feasible because
switching the device to a different VLAN after allowing unauthorized access
for booting and then providing credentials to authenticate the device (or
the user) will result in the device freezing and thus being useless, then
that just is so, and I have to deal with it.


Why would that *have* to result in the device freezing?  You can PXE boot to a
kernel and initrd that after it's downloaded runs just fine without any
network access at all.


Like I said, they are x2go clients booting from the x2go server.  Switching
them to another VLAN from where they can´t reach the server is basically the
same as unplugging the network cable, in which case they freeze until the
connection is restored, and giving them access to the server so that they can
boot before they are authorized is useless when I don´t want to allow network
access for unauthorized clients, and it is pointless because they would already
have the access they are supposed to have only after they are authorized.


There's no requirement for a PXE client to have network access to anything
other than a VLAN with a boot server that provides it with a boot image.  You
can obviously add on frippery that only recognises approved MACs for even this
if you feel the need.


Sure, but how great may the lengths be you can go before it is not reasonably
feasible to do what you´re doing?


Right, but what about keeping track of customers?  Apparently RADIUS has
some accounting features, and it might be an advantage to use those.


I really don't get why you want WPA2 Enterprise for this setup.  There's a
reason why almost everyone uses captive portals for providing access to lots
of external users.


I didn´t say I want that, and I don´t know yet what I want.  A captive portal 
may
be nice, but I haven´t found a way to set one up yet, and I don´t have an access
point controller which would provide one, so I can´t tell if that´s the right
solution.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] pid_max

[Jerry Geis]

Hi Peter, Thanks... The machine with the higher PID number is a Xeon while
the other one is a i7.
So that could be why its different.

Thanks

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

[CentOS] CentOS-announce Digest, Vol 157, Issue 1

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CESA-2018:0349 Important CentOS 6 java-1.7.0-openjdk Security
  Update (Johnny Hughes)
   2. CESA-2018:0349 Important CentOS 7 java-1.7.0-openjdk Security
  Update (Johnny Hughes)
   3. CESA-2018:0350 Important CentOS 7 gcab Security   Update
  (Johnny Hughes)


--

Message: 1
Date: Wed, 28 Feb 2018 11:23:40 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0349 Important CentOS 6
java-1.7.0-openjdk Security Update
Message-ID: <20180228112340.ga58...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2018:0349 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0349

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
25621bf1dabaf8d41c99d1442ce2cd88eb00635ac1197bc5d4af967edb640911  
java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el6_9.i686.rpm
fd90cfe03e59ba60e0f7839ecab2320c49fc6279ea484c71a430d930c907e29a  
java-1.7.0-openjdk-demo-1.7.0.171-2.6.13.0.el6_9.i686.rpm
b06939f1a4c10e735464804d50f0cb41a1b33a3f1f23652bbcfc730c3e841a17  
java-1.7.0-openjdk-devel-1.7.0.171-2.6.13.0.el6_9.i686.rpm
8b1c571ceafaa9ef20510f0aed1b6986e5e138f9c61650c380678df7479759bb  
java-1.7.0-openjdk-javadoc-1.7.0.171-2.6.13.0.el6_9.noarch.rpm
0af4d015904759c1baa612ec873ff249ce01114c770961f7cb1663b7923acba1  
java-1.7.0-openjdk-src-1.7.0.171-2.6.13.0.el6_9.i686.rpm

x86_64:
a2fbc3409ece060461e3078e6c89574130ef5b3c61296619a1f92f22938116e2  
java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el6_9.x86_64.rpm
5f9392cda539d562e03fd78928fc13e08dc7800ebbbdeefd6f10ca0f5afadffe  
java-1.7.0-openjdk-demo-1.7.0.171-2.6.13.0.el6_9.x86_64.rpm
a37bab5c919e367a443d66a67959aad210f2819b7e5a16fb349b462d7347129c  
java-1.7.0-openjdk-devel-1.7.0.171-2.6.13.0.el6_9.x86_64.rpm
8b1c571ceafaa9ef20510f0aed1b6986e5e138f9c61650c380678df7479759bb  
java-1.7.0-openjdk-javadoc-1.7.0.171-2.6.13.0.el6_9.noarch.rpm
6fc3136630f186350a4d77543fa62048dee2da8702cbd4dad8b840d844113663  
java-1.7.0-openjdk-src-1.7.0.171-2.6.13.0.el6_9.x86_64.rpm

Source:
fdf94e5cfc95f0556f3e1171ad8a2d1dc462d84ed4c611786ff058e2fe1189cb  
java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 2
Date: Wed, 28 Feb 2018 11:24:45 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0349 Important CentOS 7
java-1.7.0-openjdk Security Update
Message-ID: <20180228112445.ga58...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2018:0349 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0349

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
6f912645f951cbaa4bdecf0e8ebf94989d449347354b523cf564cc1878f4cf6d  
java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm
9cf6333d77597fa9105ffd9dfbda0834d1559d5c8ea96b2c534d52e351ccb22d  
java-1.7.0-openjdk-accessibility-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm
3488e88d268a606ff504c7fce522979574840a4bc3622329d0f1937cf25809a0  
java-1.7.0-openjdk-demo-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm
db2bacd8b44684ed3ec345312a5735a30cb43522e685b6b50b7952949242b9ae  
java-1.7.0-openjdk-devel-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm
682a3b811be97f896cc96cacb8a0305bc36a144579868fa7db8f3b80447a319e  
java-1.7.0-openjdk-headless-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm
261e18e5fe67c742c69eefcdd60172d866aafd2c36e31dfe12afffdd464f22be  
java-1.7.0-openjdk-javadoc-1.7.0.171-2.6.13.0.el7_4.noarch.rpm
0b80b903b2e1dda0bb1b19f5bab3f5ea56fb3ab0418004ffbc05d0169ac55677  
java-1.7.0-openjdk-src-1.7.0.171-2.6.13.0.el7_4.x86_64.rpm

Source:
0638716bc311fcd8b41c25eb918957d9bcc8d8d90bbff6becfbad8e12a2f2805  
java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el7_4.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 3
Date: Wed, 28 Feb 2018 11:25:25 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0350 Important CentOS 7 gcab
Security

Re: [CentOS] RADIUS

[John Hodrien]

This is really nothing to do with CentOS anymore, if it ever was.

On Thu, 1 Mar 2018, hw wrote:


If PXE boot is not possible because it would require to allow network access
to unauthorized devices, or if it is not reasonably feasible because
switching the device to a different VLAN after allowing unauthorized access
for booting and then providing credentials to authenticate the device (or
the user) will result in the device freezing and thus being useless, then
that just is so, and I have to deal with it.


Why would that *have* to result in the device freezing?  You can PXE boot to a
kernel and initrd that after it's downloaded runs just fine without any
network access at all.

There's no requirement for a PXE client to have network access to anything
other than a VLAN with a boot server that provides it with a boot image.  You
can obviously add on frippery that only recognises approved MACs for even this
if you feel the need.


Right, but what about keeping track of customers?  Apparently RADIUS has
some accounting features, and it might be an advantage to use those.


I really don't get why you want WPA2 Enterprise for this setup.  There's a
reason why almost everyone uses captive portals for providing access to lots
of external users.

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

Re: [CentOS-virt] qemu-guest-agent doesnt start

[Nerijus Baliūnas]

2018-03-01 13:09, Aleksey Kashin rašė:

Hello,

I need to communicate with windows 10 guest from cent os host.

Following this docs - https://access.redhat.com/solutions/732773,
https://wiki.libvirt.org/page/Qemu_guest_agent I add new device in my Win10 
guest



   


and install gemu-ga x64 from this iso -
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.141-1/virtio-win-0.1.141.iso


That's OK.

After that I install gemu-guest-agent on cent os host and try to start 
service but with no success


Why do you install agent on host? You don't need to.

Regards,
Nerijus
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] qemu-guest-agent doesnt start

[Aleksey Kashin]

Hello,

I need to communicate with windows 10 guest from cent os host.

Following this docs - https://access.redhat.com/solutions/732773,
https://wiki.libvirt.org/page/Qemu_guest_agent I add new device in my Win10
guest


   


and install gemu-ga x64 from this iso -
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.141-1/virtio-win-0.1.141.iso

After that I install gemu-guest-agent on cent os host and try to start
service but with no success

[root@kvm ~]# service qemu-guest-agent start
Redirecting to /bin/systemctl start qemu-guest-agent.service
A dependency job for qemu-guest-agent.service failed. See 'journalctl -xe'
for details.

[root@kvm ~]# journalctl -xe
мар 01 15:41:03 kvm.office systemd[1]: Job
dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out.
мар 01 15:41:03 kvm.office systemd[1]: Timed out waiting for device
dev-virtio\x2dports-org.qemu.guest_agent.0.device.
-- Subject: Unit dev-virtio\x2dports-org.qemu.guest_agent.0.device has
failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit dev-virtio\x2dports-org.qemu.guest_agent.0.device has failed.
-- 
-- The result is timeout.
мар 01 15:41:03 kvm.office systemd[1]: Dependency failed for QEMU Guest
Agent.
-- Subject: Unit qemu-guest-agent.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit qemu-guest-agent.service has failed.
-- 
-- The result is dependency.
мар 01 15:41:03 kvm.office systemd[1]: Job qemu-guest-agent.service/start
failed with result 'dependency'.
мар 01 15:41:03 kvm.office systemd[1]: Job
dev-virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result
'timeout'.
мар 01 15:41:03 kvm.office polkitd[1376]: Unregistered Authentication Agent
for unix-process:27927:138320296 (system bus name :1.885, object path
/org/freedesktop/PolicyKit1/AuthenticationAg


Also I tried to start qemu-ga wrapped by strace

[root@kvm ~]# source /etc/sysconfig/qemu-ga
[root@kvm ~]# strace /usr/bin/qemu-ga \
>   --method=virtio-serial \
>   --path=/dev/virtio-ports/org.qemu.guest_agent.0 \
>   --blacklist=${BLACKLIST_RPC} \
>   -F${FSFREEZE_HOOK_PATHNAME}



open("/dev/virtio-ports/org.qemu.guest_agent.0",
O_RDWR|O_NONBLOCK|O_ASYNC|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "1519901353.794545: critical: err"..., 781519901353.794545:
critical: error opening channel: No such file or directory
) = 78
write(2, "1519901353.794659: critical: err"..., 511519901353.794659:
critical: error opening channel
) = 51
write(2, "1519901353.794742: critical: fai"..., 661519901353.794742:
critical: failed to create guest agent channel
) = 66
write(2, "1519901353.794818: critical: fai"..., 701519901353.794818:
critical: failed to initialize guest agent channel
) = 70
exit_group(1)   = ?
+++ exited with 1 +++


[root@kvm ~]# ls -l /dev/virtio-ports/*
ls: cannot access /dev/virtio-ports/*: No such file or directory


Anybody help me?


Centos 7.2

[root@kvm ~]# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

[root@kvm ~]# uname -r
3.10.0-327.el7.x86_64

Qemu-guest-agent v2.8

[root@kvm ~]# rpm -qa | grep qemu-guest
qemu-guest-agent-2.8.0-2.el7.x86_64

Other packages

[root@kvm systemd]# rpm -qa | egrep -i 'qemu|kvm|libvirt'
libvirt-client-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-config-nwfilter-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.7.x86_64
libvirt-3.2.0-14.el7_4.7.x86_64
centos-release-qemu-ev-1.0-2.el7.noarch
qemu-kvm-common-ev-2.9.0-16.el7_4.13.1.x86_64
libvirt-daemon-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-lxc-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-3.2.0-14.el7_4.7.x86_64
qemu-img-ev-2.9.0-16.el7_4.13.1.x86_64
libvirt-libs-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-config-network-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-interface-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
qemu-kvm-ev-2.9.0-16.el7_4.13.1.x86_64
libvirt-python-3.2.0-3.el7_4.1.x86_64
libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-secret-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-network-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.7.x86_64
qemu-guest-agent-2.8.0-2.el7.x86_64
libvirt-glib-1.0.0-1.el7.x86_64

Thank you!

-- 
Best regards
___
CentOS-virt mailing list
CentOS-virt@centos.org

Re: [CentOS] RADIUS

[hw]

Gordon Messmer wrote:

On 02/27/2018 08:21 AM, hw wrote:

Gordon Messmer wrote:

I've never seen anyone actually do this, but there's an article discussing it.  
It is noteworthy that this requires enforcement in the client OS, as well as 
the switch.


The article itself says that what it is describing only works within a
Windoze world.


That's what I said.


Well, it is not applicable here.


(Also, "Windoze"?  Can we at least pretend to be a community of professionals?)


I understand that it is suggested that I should give all unauthorized devices
network access (so that they can PXE boot or whatever), which is what I
don´t want to do.


It is illogical to lump all network access together into a single category.


That depends on your point of view.  When you have access to a network, you
have better chances of being able to do something you´re not supposed to than
you have when you don´t have any access at all.  That doesn´t say anything
about how it is logical or makes sense or not to create different categories
of network access.


If your device can communicate with a switch, even for the purpose of 
authenticating, then it has network access.


The device has access to the switch which, depending on what answer to an
authentication request it gets from a RADIUS server, decides if and how it
lets the device access the network.  Maybe that´s not how it works; it´s only
what I´ve been reading.


A device cannot authenticate if the processor is idle.  The processor needs 
software in order to authenticate.  If that software resides on an TFTP server, 
rather than a locally attached storage device, then the device needs limited 
network access to retrieve the software (after which it runs the software, 
authenticates the user or the device, and receives greater levels of network 
access.)

Providing a VLAN on which there are no private resources, and no Internet 
access, may be a required component if you have devices that boot via PXE.  
Honestly, people are trying to help you, but you are placing logically 
contradictory requirements on the project.


You mean I´m not allowed to say that I don´t want to allow unauthorized devices
to access the network and having some that use PXE boot because it makes ppl 
trying
to help think that this is contradictory.  I can´t help that because it is the
situation I have to deal with.  Live is generally full of contradictions, and
everyone has to deal with that.

I don´t see what the problem is other than ppl trying to decide for me what I am
allowed to say or to think or to have to deal with, and that is something I very
much dislike.  It isn´t helpful, either.

If PXE boot is not possible because it would require to allow network access to
unauthorized devices, or if it is not reasonably feasible because switching the
device to a different VLAN after allowing unauthorized access for booting and 
then
providing credentials to authenticate the device (or the user) will result in 
the
device freezing and thus being useless, then that just is so, and I have to deal
with it.


I also understand that it may be possible that there is a variety of PXE boot
which addresses this problem by allowing devices to authenticate before they
boot.  However, some of the devices in question are likely to old to support
this.


The device needs to have software adequate to authenticate itself or its user.  
It's logically possible to run software from some local storage, authenticate, 
retrieve a new software image from PXE, and then chainload that.  If you don't 
have a device that does that, specifically, then you need to provide a VLAN 
that supports the devices you DO have.


Other options would be not to use PXE boot or to allow the devices network
access as needed.




Where do your hypothetical customers in a store get the user credentials that 
you want to authenticate via RADIUS?


They might get it from employees of the store or read it from signs
inside the store, perhaps depending on what kind of access rights they
are supposed to have.


If you're sharing passwords, then you don't need RADIUS.  Set up separate SSIDs 
that are attached to VLANs with appropriate access levels, and continue using 
WPA2 Personal.  Using RADIUS will be no more secure than that.  It's not magic.


Right, but what about keeping track of customers?  Apparently RADIUS has some
accounting features, and it might be an advantage to use those.




Imagine you want to ride a horse and don´t know anything about horses. You
look for documentation about horses, and the only documentations you can find
are telling you that horses exist, how to get one and that they can be used for
riding.  How helpful is that?


Imagine that someone is trying to help you learn to ride horses, and you spend 
all of your time complaining that you think animals are dirty. How helpful is 
that?


This analogy doesn´t apply.  It´s more like I´m wondering if the horse can be
fast enough or haul the load I might need to get 

Re: [CentOS] pid_max

[Peter Kjellström]

On Wed, 28 Feb 2018 15:15:59 -0500
Jerry Geis  wrote:

> I have two systems both running CentOS 7.4
> 
> one shows pid_max as 32768
> the other shows pid_max as 49152
> 
> Why might that be ? I would have thought they would be the same. I
> have not changed them.

I think that max is calculated as a function of number of CPUs. Maybe
those two installations differ in that regard?

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

Re: [CentOS] pid_max

[hw]

Jerry Geis wrote:

I have two systems both running CentOS 7.4

one shows pid_max as 32768
the other shows pid_max as 49152

Why might that be ? I would have thought they would be the same. I have not
changed them.


Where does it come from, tuned profiles?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos