Re: [CentOS] Admins supporting both RHEL and CentOS

[Sorin Srbu]

> -Original Message-
> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Joseph L.
> Casale
> Sent: den 30 november 2017 01:25
> To: CentOS mailing list 
> Subject: Re: [CentOS] Admins supporting both RHEL and CentOS
> 
> -Original Message-
> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Sorin Srbu
> Sent: Wednesday, November 29, 2017 12:26 AM
> To: CentOS mailing list 
> Subject: Re: [CentOS] Admins supporting both RHEL and CentOS
> 
> > Seriously, some of the RHEL-boxes we use, require a particular point
> release
> > as well as not allowing any updates to the OS. At all.
> 
> Any of the vendors on those boxes happen to be Oracle or Netcracker?

No, it's Varian/Agilent. A big player in lab instruments.

Funny thing, just googled them and apparently they've opensoured the culprit
software, and according to the below link, it's not locked to a particular
point release anymore!

http://openvnmrj.org/Downloading/

It does however still require the original software - which _is_ locked to a
particular point release. Dammit', so close!

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

Re: [CentOS] Admins supporting both RHEL and CentOS

[Joseph L. Casale]

-Original Message-
From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Sorin Srbu
Sent: Wednesday, November 29, 2017 12:26 AM
To: CentOS mailing list 
Subject: Re: [CentOS] Admins supporting both RHEL and CentOS

> Seriously, some of the RHEL-boxes we use, require a particular point release
> as well as not allowing any updates to the OS. At all.

Any of the vendors on those boxes happen to be Oracle or Netcracker?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Joseph L. Casale]

-Original Message-
From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Peter Eckel
Sent: Wednesday, November 29, 2017 5:21 AM
To: CentOS mailing list 
Subject: Re: [CentOS] Admins supporting both RHEL and CentOS

> While that may seem a bit strange insofar as the upgrade mechanism with
> RHEL works quite the same as with CentOS by default (running updates
> regularly will make RHEL cross .x boundaries when they are reached), the
> different behaviour might come from three facts: 1. some vendors restrict
> their support to specific .x releases, 2. RHEL systems tend to run in
> production environments more often than CentOS systems, so they are
> subject to stricter rules regarding testing and clearance of updates, and 3.
> maintaining a RHN satellite or allowing internet access for RHN-registered
> systems is not part of the enterprise's IT strategy (don't laugh).

So at the current shop I am in, they have updates provided by Satellite and
the channel is locked on the point release. I just wondered how common this
was.

Thanks for all insight everyone.

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

Re: [CentOS] Failed attempts

[Anthony K]

On 28/11/17 06:02, m.r...@5-cent.us wrote:

Pete Biggs wrote:

On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:

   - don't run ssh on 22, use a different port.  (Things get a lot
quieter when you do that, but it comes with it's own problems and don't
get complacent because someone will find the port eventually.)

I consider that pointless security-through-obscurity.


I actually have SSH running on port 22 - however, I stipulate a 
different port in a PREROUTING/DNAT rule for external access for those 
hotels that block VPN access (yes, there are still some out there).  
Internal users need not change their habits.  In addition, this helps 
keep my logs clean...


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

[CentOS] C7 and docker storage

[m . roth]

Was working on docker on a server, and on startup, I see
Nov 29 10:58:27  dockerd-current:
time="2017-11-29T10:58:27.612849959-05:00" level=warning msg="devmapper:
Usage of loopback devices is strongly discouraged for production use.
Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to
dm.thinpooldev section."
Nov 29 10:58:27  dockerd-current:
time="2017-11-29T10:58:27.655600686-05:00" level=warning msg="devmapper:
Base device already exists and has filesystem xfs on it. User specified
filesystem  will be ignored."

The latter would explain the message my user's job gave him when it tried
to umount /

A bit of googling, and I see something called overlayFS can be used... but
I know nothing about that, or how dangerous it is.  Anyone got a pointed
to something more than the minimal how to configure docker to use it?

mark

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

Re: [CentOS] Missing /usr/share/perl5 in C7

[m . roth]

Mark Haney wrote:
> On 11/29/2017 01:43 PM, m.r...@5-cent.us wrote:
>> Mark Haney wrote:
>
>>>
>>> Any idea what happened?
>>
>> No idea what could have happened, but if it were me, I wouldn't copy
>> anything - I'd yum reinstall instantly. You have no idea what *else* is
>> missing.
>>
>> Thinking about it... you might consider verifying the entire system.
>> Since something's missing from initscripts, I'd worry a *lot*.
>
> Believe me, I am.  Unfortunately and unbeknownst to me, this box has
> been in production on the customer side for a couple of weeks now.
> I've checked every other box that's been kickstarted for the last month
> and none show the same problems.  It's really bizarre.

Some admin ran find / -exec rm -f {} \;, when they meant to run find
/somepathorother.
>
> And as far as the /etc/init.d/functions file goes, C7 doesn't place it
> there, it's in /etc/rc.d/init.d/functions, so symlinking to it from
> /etc/init.d/ fixed that particular problem.
>
> The weird issue with /usr/share/perl5/ is that there was some files and
> directories there, just not everything, so it wasn't completely empty.
> I have no real answer to that, though.
>
> But, right now, the box is stable for what it will be doing, and I've
> got a production MySQL server to troubleshoot why it's imploded twice
> the last two nights after being up for 400 days without trouble.
>
> The joys of dealing with multiple dumpster fires at a time is why I love
> (and hate) IT.
>
Best of luck.

mark

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

Re: [CentOS] Missing /usr/share/perl5 in C7

[Peter]

On 30/11/17 08:40, Mark Haney wrote:
> On 11/29/2017 01:43 PM, m.r...@5-cent.us wrote:
>> Mark Haney wrote:
> 
>>>
>>> Any idea what happened?

I'd say at best (and likely) a botched install, at worst something more
malicious.

>> No idea what could have happened, but if it were me, I wouldn't copy
>> anything - I'd yum reinstall instantly. You have no idea what *else* is
>> missing.
>>
>> Thinking about it... you might consider verifying the entire system.
>> Since
>> something's missing from initscripts, I'd worry a *lot*.

I'd run "rpm -Va" and examine the output.  Anything it shows in the
output is something that differs from what should be installed and what
actually is.  See the rpm man page for details.

Run yum reinstall for any package that appears to have issues.

> Believe me, I am.  Unfortunately and unbeknownst to me, this box has
> been in production on the customer side for a couple of weeks now.

It should still be fine to run yum reinstall on a package, unless the
customer has actually done something to rely on the brokenness of the
system.

> And as far as the /etc/init.d/functions file goes, C7 doesn't place it
> there, it's in /etc/rc.d/init.d/functions, so symlinking to it from
> /etc/init.d/ fixed that particular problem.

/etc/init.d is supposed to be a symbolic link to /etc/rc.d/init.d, if
they're not then you need to fix that, and before you fix that you'll
need to move any scripts you put inside it to /etc/rc.d.init.d.  The
damage you're seeing here is because they have somehow become separate
directories on the server.

> But, right now, the box is stable for what it will be doing,

I would not call that stable, I can just about guarantee that it will
have problems down the road if you keep running it in this state.


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

Re: [CentOS] Missing /usr/share/perl5 in C7

[Mark Haney]

On 11/29/2017 01:43 PM, m.r...@5-cent.us wrote:

Mark Haney wrote:




Any idea what happened?


No idea what could have happened, but if it were me, I wouldn't copy
anything - I'd yum reinstall instantly. You have no idea what *else* is
missing.

Thinking about it... you might consider verifying the entire system. Since
something's missing from initscripts, I'd worry a *lot*.

   mark



Believe me, I am.  Unfortunately and unbeknownst to me, this box has 
been in production on the customer side for a couple of weeks now. 
I've checked every other box that's been kickstarted for the last month 
and none show the same problems.  It's really bizarre.


And as far as the /etc/init.d/functions file goes, C7 doesn't place it 
there, it's in /etc/rc.d/init.d/functions, so symlinking to it from 
/etc/init.d/ fixed that particular problem.


The weird issue with /usr/share/perl5/ is that there was some files and 
directories there, just not everything, so it wasn't completely empty. 
I have no real answer to that, though.


But, right now, the box is stable for what it will be doing, and I've 
got a production MySQL server to troubleshoot why it's imploded twice 
the last two nights after being up for 400 days without trouble.


The joys of dealing with multiple dumpster fires at a time is why I love 
(and hate) IT.



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Missing /usr/share/perl5 in C7

[m . roth]

Mark Haney wrote:
> I'm under a bit of a crunch here, so any immediate help would be
> appreciated. We kickstart our customer boxes and have started migrating
> to CentOS 7.  We're running Radiator 4.6 1 (I know, but bear with me)
> and we just deployed our first radius box to a customer to be turned up
> today. (I know, I know. I had no idea it wasn't being tested sooner than
> this.)
>
> I was brought in because the strict.pm perl module was missing and
> causing compilation errors.  It turns out nearly the entire
> /usr/share/perl5/  directory was pretty much empty.  I ended up having
> to copy that directory over from another C7 server which was intact.
>
> yum whatprovides /usr/share/perl5/strict.pm tells me it's the base
> perl-5.16.x package, which is installed on this box.
>
> Any idea what happened?

No idea what could have happened, but if it were me, I wouldn't copy
anything - I'd yum reinstall instantly. You have no idea what *else* is
missing.

Thinking about it... you might consider verifying the entire system. Since
something's missing from initscripts, I'd worry a *lot*.

  mark

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

Re: [CentOS] Perl fun part 2

[Chris Adams]

Once upon a time, Mark Haney  said:
> Along with the /usr/share/perl5 issues (which I did kinda fix with a
> manual copy of the directory from another box), we're having an
> issue with SystemD (go figure) stopping the radiator service, but
> failing to unbind the ports (1645/1646).  It's complaining about
> 'killproc' not found.

Unless you've converted it, an old service is probably still using the
SysV init-script mode of startup/management.  In that case, systemd does
not bind any ports (because there's no config for that).  Are you sure
it is actually shutting the service down?

If systemd is binding the ports, then there's a systemd unit file
somewhere (under /usr/lib/systemd/system or /etc/systemd/system)
specifying that.

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

Re: [CentOS] Missing /usr/share/perl5 in C7

[Pete Biggs]

On Wed, 2017-11-29 at 12:28 -0500, Mark Haney wrote:
> I'm under a bit of a crunch here, so any immediate help would be 
> appreciated. We kickstart our customer boxes and have started migrating 
> to CentOS 7.  We're running Radiator 4.6 1 (I know, but bear with me) 
> and we just deployed our first radius box to a customer to be turned up 
> today. (I know, I know. I had no idea it wasn't being tested sooner than 
> this.)
> 
> I was brought in because the strict.pm perl module was missing and 
> causing compilation errors.  It turns out nearly the entire 
> /usr/share/perl5/  directory was pretty much empty.  I ended up having 
> to copy that directory over from another C7 server which was intact.
> 
> yum whatprovides /usr/share/perl5/strict.pm tells me it's the base 
> perl-5.16.x package, which is installed on this box.
> 
> Any idea what happened?
> 

Obviously something has removed everything - perhaps some over jealous
script.  Could you not just do 'yum reinstall perl'.

P.


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

Re: [CentOS] Perl fun part 2

[Pete Biggs]

> Along with the /usr/share/perl5 issues (which I did kinda fix with a 
> manual copy of the directory from another box), we're having an issue 
> with SystemD (go figure) stopping the radiator service, but failing to 
> unbind the ports (1645/1646).  It's complaining about 'killproc' not 
> found.
> 
> Is there a package that's in?  Or how do I get this to work with SystemD 
> properly?  We can't have this thing jacked up like this.
> 

killproc() is a shell function defined in /etc/init.d/functions and
that is provided by the package "initscripts".  The "functions" file is
in effect a library of scripts used by the sysv init scripts and it is
sourced at the top of every file in /etc/init.d  

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

[CentOS] Perl fun part 2

[Mark Haney]

I figured this needed it's own thread, so apologies for spamming the list.

Along with the /usr/share/perl5 issues (which I did kinda fix with a 
manual copy of the directory from another box), we're having an issue 
with SystemD (go figure) stopping the radiator service, but failing to 
unbind the ports (1645/1646).  It's complaining about 'killproc' not 
found.


Is there a package that's in?  Or how do I get this to work with SystemD 
properly?  We can't have this thing jacked up like this.


Any ideas?

--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Missing /usr/share/perl5 in C7

[Mark Haney]

I'm under a bit of a crunch here, so any immediate help would be 
appreciated. We kickstart our customer boxes and have started migrating 
to CentOS 7.  We're running Radiator 4.6 1 (I know, but bear with me) 
and we just deployed our first radius box to a customer to be turned up 
today. (I know, I know. I had no idea it wasn't being tested sooner than 
this.)


I was brought in because the strict.pm perl module was missing and 
causing compilation errors.  It turns out nearly the entire 
/usr/share/perl5/  directory was pretty much empty.  I ended up having 
to copy that directory over from another C7 server which was intact.


yum whatprovides /usr/share/perl5/strict.pm tells me it's the base 
perl-5.16.x package, which is installed on this box.


Any idea what happened?



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-es] Servidor Web Centos7

[Wilmer Arambula]

Gracias con eso veré como se hace la instalación y lo afinare sin usar el
panel,

Slds.

El mar., 28 nov. 2017 a las 10:05, Henry Rosado ()
escribió:

> No se si te sirve cwp7 que ya trae esos proxys inversos
>
> El 27 nov. 2017 20:36, "Wilmer Arambula" 
> escribió:
>
> > Buenas noches se que la lista es de Centos, pero quiero consultar lo
> > siguiente tengo un VPS KVM de 4GBRAM y 100GBSSD voy alojar un cms de
> > aplicaciones móviles en ionic, angular y requiero un servidor web rápido
> he
> > visto LNAMP que es Apache con servidor NINGX proxy en su experiencia cual
> > seria mi mejor configuración  el VPS trae por defecto HAPROXY a traves de
> > SOLUSVM que tutorial me recomiendan o algún script en Google hay
> demasiado
> > material y aquí es donde la experiencia hace diferencia gracias.
> >
> > Wilmer.
> > ___
> > CentOS-es mailing list
> > CentOS-es@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-es
> >
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] C 7, lockd issue

[James Pearson]

m.r...@5-cent.us wrote:
> 
> I thnk I posted this last week, but to refresh your minds (for Americans,
> after all the turkey): two C7 boxes, updated. box 1 is exporting
> directories; box 2 is not running nfs.  From box 1, every minute, I get
> <...> kernel: lockd: server fred.local not responding, timed out
> 
> Now, on box 2, fred is eth0:fred, and is one of five secondaries on eth0.
> When I do an ip a, it shows as the last one. Further, df shows no
> directory from box 1 being mounted.
> 
> So, does anyone have a clue on this?

Does 'box 1' have the files /var/lib/nfs/statd/{sm,sm.bak}/fred.local ?

If so, try removing these files - you may need to stop nfslock on 'box 
1' before removing - and restart after

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

[CentOS] C 7, lockd issue

[m . roth]

I thnk I posted this last week, but to refresh your minds (for Americans,
after all the turkey): two C7 boxes, updated. box 1 is exporting
directories; box 2 is not running nfs.  From box 1, every minute, I get
<...> kernel: lockd: server fred.local not responding, timed out

Now, on box 2, fred is eth0:fred, and is one of five secondaries on eth0.
When I do an ip a, it shows as the last one. Further, df shows no
directory from box 1 being mounted.

So, does anyone have a clue on this?

   mark

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

Re: [CentOS] Failed attempts

[Robert Nichols]

On 11/28/2017 11:04 AM, Valeri Galtsev wrote:> I was always unimpressed with> persistence of attempts to make 
more secure (less pickable) cylinder cased> locks (precision, multi-level, pins at a weird locations/angles). 
Whereas> there exists "disk based design" (should I say Abloy?), which with my> knowledge of mechanics 
I can not figure the way to pick. So I consider> them un-pickable. Why aren't they widely used [in US]? Because 
there may> be the reason for powers there be to have locks everywhere pickable. On> the other hand, I do not have 
Abloy locks, as they do keep records that> link my particular lock to key that opens it. So, there is viable 
vector> of attack ;-)
A quick YouTube search for "abloy lock picking" might change your opinion.
It takes a special tool, but those are available and not all that hard
to make.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

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

Re: [CentOS] Admins supporting both RHEL and CentOS

[Johnny Hughes]

On 11/29/2017 05:14 AM, James Hogarth wrote:
> On 28 November 2017 at 16:06, Johnny Hughes  wrote:
>> On 11/28/2017 08:20 AM, James Hogarth wrote:
>>> On 28 November 2017 at 13:48, Mark Haney  wrote:
 On 11/28/2017 08:06 AM, Joseph L. Casale wrote:
>
> With a few exceptions, I see most admins treat CentOS as a single
> rolling release and rely on the ABI commitment assuming things
> just work between point releases. On the other hand I see the
> opposite with RHEL where admins constrain installations to the
> point release.
>
> What is the case with users on this list who support both?


 I can't really speak for anyone else, but for me, a lot depends on the use
 of the systems.  I typically treat RHEL and CentOS the same way as far as
 updating to the latest point release.  It's never bit me in the past that I
 am aware of.

 The only exception to that is with the SGI Altix 4300/4400s I used to
 manage.  We migrated from SLES to RHEL and in those cases, barring a 
 serious
 enough bug, those boxes were left alone until time came to refresh them,
 such as the move from RHEL5 to RHEL6.


>>>
>>>
>>> Note that RHEL is a special case as there's some situations companies
>>> will pay out for the Extended Update Support (EUS)[0] in order to stay
>>> on a particular milestone for longer.
>>>
>>> In addition there is the slight bonus of access to beta of the next
>>> milestone or major release which may affect your workflow if you have
>>> a suitable test environment, and of course you'll get the milestone
>>> quicker on release so that needs to be paid attention to for testing.
>>>
>>> Outside of this area the two can be, and should be, treated
>>> identically in terms of update policies.
>>>
>>>
>>>
>>> [0] https://access.redhat.com/support/policy/updates/errata
>>
>> And also note that Red Hat does not publicly release the SRPMs for their
>> EUS packages.  The CentOS Project therefore can not build those, so
>> there is NO EUS in CentOS Linux.  The only way to get Security updates
>> in CentOS Linux is to be on the current (latest) point release.
>>
>> Also, since all updates are built against the current (latest) release
>> as they are released, there is no way to get only security updates in
>> CentOS Linux.  You could TRY to only install security updates on your
>> own .. however, since there are rebases during point releases, things
>> that are built against the newer openssl will not work with older ssl's
>> OR things build against the newer gnome will not work with older
>> gnome's, etc.
>>
>> The only tested way to run CentOS Linux is with all the updates
>> installed together.
>>
>>
>>
> 
> Even Red Hat technically on RHEL doesn't "support" only installing
> updates marked security as they always have an assumption all previous
> errata are applied.

That is indeed correct and it is on every errata released from Red Hat:

"Before installing an update, make sure all previously released errata
relevant to the system have been applied."

Therefore the only real difference in recommendations is that EUS is
available in RHEL packages.



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

Re: [CentOS] Admins supporting both RHEL and CentOS

[Peter Eckel]

Hi Joseph, 

> On 28. Nov 2017, at 14:06, Joseph L. Casale  wrote:
> 
> With a few exceptions, I see most admins treat CentOS as a single rolling 
> release and rely on the ABI commitment assuming things just work between 
> point releases. On the other hand I see the opposite with RHEL where admins 
> constrain installations to the point release.

I concur with the latter: I also often see RHEL installations where the admins 
assume they are running "RHEL 7.3" rather than "RHEL 7". In some cases there 
isn't even an upgrade mechanism in place: Systems are installed from ISO images 
(usually by the solution vendor) and there are no upgrades whatsoever until the 
system gets decommissioned.

While that may seem a bit strange insofar as the upgrade mechanism with RHEL 
works quite the same as with CentOS by default (running updates regularly will 
make RHEL cross .x boundaries when they are reached), the different behaviour 
might come from three facts: 1. some vendors restrict their support to specific 
.x releases, 2. RHEL systems tend to run in production environments more often 
than CentOS systems, so they are subject to stricter rules regarding testing 
and clearance of updates, and 3. maintaining a RHN satellite or allowing 
internet access for RHN-registered systems is not part of the enterprise's IT 
strategy (don't laugh).

> What is the case with users on this list who support both?

I for my part treat RHEL and CentOS basically the same with respect to upgrades 
wherever possible: The test stages are quite near to the current bleeding-edge 
release (if that expression is not too far-fetched for an enterprise 
distribution), and after successful testing (usually a couple of weeks to a 
month, with the exception of security updates which are higher prioritised) 
they go into production.

Cheers, 

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

[CentOS] CentOS-announce Digest, Vol 153, Issue 7

[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. Announcing release of MongoDB 3.4 on CentOS Linux 6 x86_64
  (Jan Stan?k)
   2. Announcing release of MongoDB 3.4 on CentOS Linux 7 x86_64
  (Jan Stan?k)
   3. Announcing release of NodeJS 8 on CentOS Linux 7  x86_64
  (Jan Stan?k)
   4. Announcing release of Python 3.6 on CentOS Linux  7 x86_64
  (Jan Stan?k)
   5. Announcing release of PHP 7.1 on CentOS Linux 7   x86_64
  (Jan Stan?k)
   6. Announcing release of Maven 3.5 on CentOS Linux 7 x86_64
  (Jan Stan?k)
   7. Announcing release of nginx 1.12 on CentOS Linux  7 x86_64
  (Jan Stan?k)
   8. Announcing release of Developer Toolset 7 on CentOS Linux 6
  x86_64 SCL (Jan Stan?k)
   9. Announcing release of MariaDB 10.2 on CentOS  Linux 7 x86_64
  SCL (Jan Stan?k)
  10. Announcing release of Developer Toolset 7 on CentOS Linux 7
  x86_64 SCL (Jan Stan?k)
  11. Announcing release of MariaDB 10.2 on CentOS  Linux 6 x86_64
  SCL (Jan Stan?k)
  12. Announcing release of PostgreSQL 9.6 on CentOSLinux 7 x86_64
  (Jan Stan?k)
  13. Announcing release of PostgreSQL 9.6 on CentOSLinux 6 x86_64
  (Jan Stan?k)
  14. CESA-2017:3270 Important CentOS 6 apr SecurityUpdate
  (Johnny Hughes)
  15. CESA-2017:3270 Important CentOS 7 apr SecurityUpdate
  (Johnny Hughes)
  16. CESA-2017:3269 Important CentOS 7 procmailSecurity Update
  (Johnny Hughes)


--

Message: 1
Date: Tue, 28 Nov 2017 15:34:31 +0100
From: Jan Stan?k 
To: centos-annou...@centos.org
Subject: [CentOS-announce] Announcing release of MongoDB 3.4 on CentOS
Linux   6 x86_64
Message-ID: 
Content-Type: text/plain; charset="utf-8"

I am pleased to announce the immediate availability of MongoDB
in version 3.4 on CentOS Linux 6 x86_64, delivered via a Software
Collection (SCL) built by the SCLo Special Interest Group
(https://wiki.centos.org/SpecialInterestGroup/SCLo).


QuickStart
--
You can get started in three easy steps:

$ sudo yum install centos-release-scl
$ sudo yum install rh-mongodb34
$ scl enable rh-mongodb34 bash

At this point you should be able to use MongoDB just as a normal
application. Some examples of usage follows:

$ service rh-mongodb34-mongod start
$ mongo

In order to view the individual components included in this collection,
including additional subpackages, you can run:

$ sudo yum list rh-mongodb34\*

This collections is CentOS-based rebuild built by SCLo SIG community,
and the packages have been available in Red Hat Software Collections 3.0
for RHEL:

https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/3.0_release_notes/

So, for RHEL-based builds, follow the steps in the documentation above.

About Software Collections
--
Software Collections give you the power to build, install, and use
multiple versions of software on the same system, without affecting
system-wide installed packages. Each collection is delivered as a group
of RPMs, with the grouping being done using the name of the collection
as a prefix of all packages that are part of the software collection.

The SCLo SIG in CentOS
--
The Software Collections SIG group is an open community group
co-ordinating the development of the SCL technology, and helping curate
a reference set of collections. In addition to the collection NodeJS
being released here, we also build and deliver databases, web servers,
and language stacks including multiple versions of PostgreSQL, MariaDB,
Apache HTTP Server, Python, Ruby, Ruby on Rails and others.

You can learn more about Software Collections concepts at:
http://softwarecollections.org
You can find information on the SIG at
https://wiki.centos.org/SpecialInterestGroup/SCLo ; this includes howto
get involved and help with the effort.

Enjoy!
-- 
Jan Stan?k
Associate Software Engineer, Brno
Red Hat Czech
jsta...@redhat.comIM: jstanek




-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: 


--

Message: 2
Date: Tue, 28 Nov 2017 15:34:43 +0100
From: Jan Stan?k 

Re: [CentOS] Admins supporting both RHEL and CentOS

[James Hogarth]

On 28 November 2017 at 16:06, Johnny Hughes  wrote:
> On 11/28/2017 08:20 AM, James Hogarth wrote:
>> On 28 November 2017 at 13:48, Mark Haney  wrote:
>>> On 11/28/2017 08:06 AM, Joseph L. Casale wrote:

 With a few exceptions, I see most admins treat CentOS as a single
 rolling release and rely on the ABI commitment assuming things
 just work between point releases. On the other hand I see the
 opposite with RHEL where admins constrain installations to the
 point release.

 What is the case with users on this list who support both?
>>>
>>>
>>> I can't really speak for anyone else, but for me, a lot depends on the use
>>> of the systems.  I typically treat RHEL and CentOS the same way as far as
>>> updating to the latest point release.  It's never bit me in the past that I
>>> am aware of.
>>>
>>> The only exception to that is with the SGI Altix 4300/4400s I used to
>>> manage.  We migrated from SLES to RHEL and in those cases, barring a serious
>>> enough bug, those boxes were left alone until time came to refresh them,
>>> such as the move from RHEL5 to RHEL6.
>>>
>>>
>>
>>
>> Note that RHEL is a special case as there's some situations companies
>> will pay out for the Extended Update Support (EUS)[0] in order to stay
>> on a particular milestone for longer.
>>
>> In addition there is the slight bonus of access to beta of the next
>> milestone or major release which may affect your workflow if you have
>> a suitable test environment, and of course you'll get the milestone
>> quicker on release so that needs to be paid attention to for testing.
>>
>> Outside of this area the two can be, and should be, treated
>> identically in terms of update policies.
>>
>>
>>
>> [0] https://access.redhat.com/support/policy/updates/errata
>
> And also note that Red Hat does not publicly release the SRPMs for their
> EUS packages.  The CentOS Project therefore can not build those, so
> there is NO EUS in CentOS Linux.  The only way to get Security updates
> in CentOS Linux is to be on the current (latest) point release.
>
> Also, since all updates are built against the current (latest) release
> as they are released, there is no way to get only security updates in
> CentOS Linux.  You could TRY to only install security updates on your
> own .. however, since there are rebases during point releases, things
> that are built against the newer openssl will not work with older ssl's
> OR things build against the newer gnome will not work with older
> gnome's, etc.
>
> The only tested way to run CentOS Linux is with all the updates
> installed together.
>
>
>

Even Red Hat technically on RHEL doesn't "support" only installing
updates marked security as they always have an assumption all previous
errata are applied.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Gnome boot problem (again :-) )

[Anthony K]

On 25/11/17 12:09, vychytraly . wrote:

Hello friends

I was using EL7 on gnome 3 for few months without any problem. Even 2 hours
ago I had the computer (Laptop running on Nvidia-Prime) turned on and
everything was working without flaw. But when I turned on the computer few
minutes ago, I got login screen (which does not usually happen, since I
have autologin turned on) and when I entered my login credentials I got
black screen and went back to login screen. Everytime I entered my
credentials the same thing happened so I was stuck in endless login loop.
At first I thought it was caused by gnome-extension I updated to new
version today.

For me, I noticed (on a different terminal - Ctrl+F2) that when I warm 
boot the laptop, the Nvidia Card is not recognized and hence I get that 
login loop.  When this happens, I simply fully shutdown laptop for a 
minute and when I boot up again, the card is found and all is well.  I 
might as well mention that I'm running Ubuntu 16.04 on my laptop so your 
problem might be different but just thought I might mention it just in 
case...


https://askubuntu.com/questions/941259/nvrm-no-nvidia-graphics-adapter-found

I used to do exactly like you - drop to shell and start messing with 
stuff until I realized that this is what was happening.  My workaround 
has been to simply shutdown, wait a minute and reboot - works always!


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