Re: [CentOS] Traffic shaping on CentOS

[Fabian Arrotin]

On 15/12/17 07:05, Kenneth Porter wrote:
> I came across this on the Fedora devel list. I added
> /etc/sysctl.d/51-bufferbloat.conf containing the suggested line and it
> installs the new codel qdisc as desired. There's probably more knobs
> that might be useful to tweak but this makes a good start. More reading
> on the bufferbloat site suggests that the later "cake" module will be
> even better, but it requires a newer kernel than CentOS currently ships
> with.
> 
> 
> 
> # 51-bufferbloat.conf
> # Address bufferbloat
> net.core.default_qdisc = fq_codel
> 

I don't know your full requirements, but in the past for simple QoS gw I
used FireQOS
It's part of https://firehol.org/ , but can be used without firehol so
in parallel of your own iptables rules

Here is the doc : https://firehol.org/tutorial/fireqos-new-user/

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab



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

Re: [CentOS] Question on CentoS 7.4 on nvidia

[Yan Li]

If you need to use a non stock kernel, you can also try to download the
latest driver directly from nvidia. The nvidia official driver is very easy
to install and works with almost all kernel versions. It can also be easily
uninstalled too.

On Dec 14, 2017 1:51 PM, "Jerry Geis"  wrote:

> I installed the elrepo kmod-nvidia and also the nvidia-detect and modules
> (see below).
>
> I had X working with the 3.10 from Centos  - but video was freezing. SO I
> thought I would try the elrepo kernel. I installed that and X does not come
> up?
>
> How do I re-make the nvidia module for 4.14.5 kernel? I want to make sure
> the kmod kernel did it.   I 'm thinking it did not.
>
> lspci | grep VGA says GT218
>
> Or  what do I look at now to see why X is not coming up?
>
> Thanks,
>
> Jerry
>
> uname -r
> 4.14.5-1.el7.elrepo.x86_64
>
>
> grep EE /var/log/Xorg.0.log
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
> Please see the
> [   136.998] (EE) NVIDIA: system's kernel log for additional error
> messages and
> [   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
> [   136.998] (EE) No devices detected.
> [   136.998] (EE)
> [   136.998] (EE) no screens found(EE)
> [   136.998] (EE)
> [   136.998] (EE) Please also check the log file at "/var/log/Xorg.0.log"
> for additional information.
> [   136.998] (EE)
> [   137.004] (EE) Server terminated with error (1). Closing log file.
>
> uname -a
>
> rpm -qa | grep kernel
> kernel-3.10.0-693.el7.x86_64
> kernel-tools-3.10.0-693.5.2.el7.x86_64
> abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
> kernel-headers-3.10.0-693.5.2.el7.x86_64
> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> kernel-devel-3.10.0-693.el7.x86_64
> kernel-3.10.0-693.5.2.el7.x86_64
> kernel-ml-4.14.5-1.el7.elrepo.x86_64
> kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
> kernel-devel-3.10.0-693.5.2.el7.x86_64
> [root@mediaport14 ~]# rpm -qa | grep kernel-ml
> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> kernel-ml-4.14.5-1.el7.elrepo.x86_64
>
>
> # rpm -qa | grep nvidia
> kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
> nvidia-detect-384.90-1.el7.elrepo.x86_64
> yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
> nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

[m . roth]

Yan Li wrote:
> If you need to use a non stock kernel, you can also try to download the
> latest driver directly from nvidia. The nvidia official driver is very
> easy to install and works with almost all kernel versions. It can also be
> easily uninstalled too.

Make sure you have the correct one, though. I have a number of systems
with older NVidia cards, and have to pick and choose the correct "legacy"
driver.

mark
>
> On Dec 14, 2017 1:51 PM, "Jerry Geis"  wrote:
>
>> I installed the elrepo kmod-nvidia and also the nvidia-detect and
>> modules
>> (see below).
>>
>> I had X working with the 3.10 from Centos  - but video was freezing. SO
>> I
>> thought I would try the elrepo kernel. I installed that and X does not
>> come
>> up?
>>
>> How do I re-make the nvidia module for 4.14.5 kernel? I want to make
>> sure
>> the kmod kernel did it.   I 'm thinking it did not.
>>
>> lspci | grep VGA says GT218
>>
>> Or  what do I look at now to see why X is not coming up?
>>
>> Thanks,
>>
>> Jerry
>>
>> uname -r
>> 4.14.5-1.el7.elrepo.x86_64
>>
>>
>> grep EE /var/log/Xorg.0.log
>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
>> Please see the
>> [   136.998] (EE) NVIDIA: system's kernel log for additional error
>> messages and
>> [   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
>> [   136.998] (EE) No devices detected.
>> [   136.998] (EE)
>> [   136.998] (EE) no screens found(EE)
>> [   136.998] (EE)
>> [   136.998] (EE) Please also check the log file at
>> "/var/log/Xorg.0.log"
>> for additional information.
>> [   136.998] (EE)
>> [   137.004] (EE) Server terminated with error (1). Closing log file.
>>
>> uname -a
>>
>> rpm -qa | grep kernel
>> kernel-3.10.0-693.el7.x86_64
>> kernel-tools-3.10.0-693.5.2.el7.x86_64
>> abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
>> kernel-headers-3.10.0-693.5.2.el7.x86_64
>> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
>> kernel-devel-3.10.0-693.el7.x86_64
>> kernel-3.10.0-693.5.2.el7.x86_64
>> kernel-ml-4.14.5-1.el7.elrepo.x86_64
>> kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
>> kernel-devel-3.10.0-693.5.2.el7.x86_64
>> [root@mediaport14 ~]# rpm -qa | grep kernel-ml
>> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
>> kernel-ml-4.14.5-1.el7.elrepo.x86_64
>>
>>
>> # rpm -qa | grep nvidia
>> kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
>> nvidia-detect-384.90-1.el7.elrepo.x86_64
>> yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
>> nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


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

Re: [CentOS] Question on CentoS 7.4 on nvidia

[vychytraly .]

I think that nvidia-detect could be helpful even on non-stock kernels to
find out if you need to use "legacy" or "non-legacy" driver :)

On Fri, Dec 15, 2017 at 4:34 PM,  wrote:

> Yan Li wrote:
> > If you need to use a non stock kernel, you can also try to download the
> > latest driver directly from nvidia. The nvidia official driver is very
> > easy to install and works with almost all kernel versions. It can also be
> > easily uninstalled too.
>
> Make sure you have the correct one, though. I have a number of systems
> with older NVidia cards, and have to pick and choose the correct "legacy"
> driver.
>
> mark
> >
> > On Dec 14, 2017 1:51 PM, "Jerry Geis"  wrote:
> >
> >> I installed the elrepo kmod-nvidia and also the nvidia-detect and
> >> modules
> >> (see below).
> >>
> >> I had X working with the 3.10 from Centos  - but video was freezing. SO
> >> I
> >> thought I would try the elrepo kernel. I installed that and X does not
> >> come
> >> up?
> >>
> >> How do I re-make the nvidia module for 4.14.5 kernel? I want to make
> >> sure
> >> the kmod kernel did it.   I 'm thinking it did not.
> >>
> >> lspci | grep VGA says GT218
> >>
> >> Or  what do I look at now to see why X is not coming up?
> >>
> >> Thanks,
> >>
> >> Jerry
> >>
> >> uname -r
> >> 4.14.5-1.el7.elrepo.x86_64
> >>
> >>
> >> grep EE /var/log/Xorg.0.log
> >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >> [   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
> >> Please see the
> >> [   136.998] (EE) NVIDIA: system's kernel log for additional error
> >> messages and
> >> [   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
> >> [   136.998] (EE) No devices detected.
> >> [   136.998] (EE)
> >> [   136.998] (EE) no screens found(EE)
> >> [   136.998] (EE)
> >> [   136.998] (EE) Please also check the log file at
> >> "/var/log/Xorg.0.log"
> >> for additional information.
> >> [   136.998] (EE)
> >> [   137.004] (EE) Server terminated with error (1). Closing log file.
> >>
> >> uname -a
> >>
> >> rpm -qa | grep kernel
> >> kernel-3.10.0-693.el7.x86_64
> >> kernel-tools-3.10.0-693.5.2.el7.x86_64
> >> abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
> >> kernel-headers-3.10.0-693.5.2.el7.x86_64
> >> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> >> kernel-devel-3.10.0-693.el7.x86_64
> >> kernel-3.10.0-693.5.2.el7.x86_64
> >> kernel-ml-4.14.5-1.el7.elrepo.x86_64
> >> kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
> >> kernel-devel-3.10.0-693.5.2.el7.x86_64
> >> [root@mediaport14 ~]# rpm -qa | grep kernel-ml
> >> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> >> kernel-ml-4.14.5-1.el7.elrepo.x86_64
> >>
> >>
> >> # rpm -qa | grep nvidia
> >> kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
> >> nvidia-detect-384.90-1.el7.elrepo.x86_64
> >> yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
> >> nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
> >> ___
> >> CentOS mailing list
> >> CentOS@centos.org
> >> https://lists.centos.org/mailman/listinfo/centos
> >>
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> >
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] GUI/X11 login and shells other than bash?

[Valeri Galtsev]

Dear Experts,

After one of updates that was released some time ago (a Month ago or maybe
even earlier) I have noticed the following. On the machines with default
runlevel 5 (sorry about old terminology, the new one is still confusing
for me ;-) GUI/X11 login (display manager) lists only users whose default
shell is bash. Or, at least users whose default shell is tcsh are not
listed at all, and if they attempt to log in just by giving their UNIX
username, their X11 session "crashes", meaning that after attempting to
start, it just trows one back to GUI/X11 login screen.

I really do not want to start this shell vs that shell flame war
(especially that I myself prefer not tcsh but sh and/or bash for
scripting...). But I respect my user's freedom of choosing default shell,
so this is really big issue IMHO.

I just wonder: does RedHat (CentOS's upstream vendor) dislike and is
willing to eradicate all shells except for bash, or what I see is just my
own pilot's error?

Thanks in advance for all your answers.

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
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] GUI/X11 login and shells other than bash?

[Stephen John Smoogen]

On 15 December 2017 at 13:24, Valeri Galtsev  wrote:
> Dear Experts,
>
> After one of updates that was released some time ago (a Month ago or maybe
> even earlier) I have noticed the following. On the machines with default
> runlevel 5 (sorry about old terminology, the new one is still confusing
> for me ;-) GUI/X11 login (display manager) lists only users whose default
> shell is bash. Or, at least users whose default shell is tcsh are not
> listed at all, and if they attempt to log in just by giving their UNIX
> username, their X11 session "crashes", meaning that after attempting to
> start, it just trows one back to GUI/X11 login screen.
>
> I really do not want to start this shell vs that shell flame war
> (especially that I myself prefer not tcsh but sh and/or bash for
> scripting...). But I respect my user's freedom of choosing default shell,
> so this is really big issue IMHO.
>
> I just wonder: does RedHat (CentOS's upstream vendor) dislike and is
> willing to eradicate all shells except for bash, or what I see is just my
> own pilot's error?
>

Just for future advise.. for someone who says they don't want to start
a flamewar.. you worded that pretty much like you wanted to start a
flame war.

This was simple to test.

1. I installed RHEL-7 in a virtual machine.
2. I created an account with its shell /bin/tcsh [useradd ssmoogen -s
/bin/tcsh ]
3. I went to the login screen. There was an ssmoogen there
4. I logged in as ssmoogen. I got a GNOME desktop
5. I opened a terminal and my shell was tcsh.

That took me 10 minutes. Due to this I am going to say that there is
something wrong with other parts of the start up environment from what
the shell is listed as in /etc/passwd, if the user has specific
startup scripts .xsession items or some similar problem based on
'shell cruft'. People who work on many different systems have to
regularly add exceptions and special cases or unadd them when they
find stuff breaks. I would also check to see if there is a post
configuration setup which changed /etc/shells on the system. Another
common problem is that the shell or startsups are looking for
/usr/local/bin/tcsh which doesn't exist.

Red Hat has a lot of different developers using pretty much every
shell that is shipped in RHEL and some which aren't even in Fedora.
The developers also use all kinds of different desktops and software..
while this doesn't mean bugs won't happen.. it does mean that if 'Red
Hat' was out to eradicate other shells, there would be posts on every
hacker site from Red Hat employees who wouldn't put up with it.



> Thanks in advance for all your answers.
>
> 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
> 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] Traffic shaping on CentOS

[Kenneth Porter]

On 12/15/2017 4:10 AM, Fabian Arrotin wrote:

I don't know your full requirements, but in the past for simple QoS gw I
used FireQOS
It's part ofhttps://firehol.org/  , but can be used without firehol so
in parallel of your own iptables rules


That looks nice. It appears to be a declarative front-end to tc that 
eliminates some of the boilerplate like setting defaults.


The gateway is for a small business and I don't want shell and remote 
desktop sessions to come to a crawl because someone's 
uploading/downloading/mailing a big CAD file to a customer/vendor, or 
because several are watching Youtube videos.


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

Re: [CentOS] GUI/X11 login and shells other than bash?

[Valeri Galtsev]

On Fri, December 15, 2017 2:34 pm, Stephen John Smoogen wrote:
> On 15 December 2017 at 13:24, Valeri Galtsev 
> wrote:
>> Dear Experts,
>>
>> After one of updates that was released some time ago (a Month ago or
>> maybe
>> even earlier) I have noticed the following. On the machines with default
>> runlevel 5 (sorry about old terminology, the new one is still confusing
>> for me ;-) GUI/X11 login (display manager) lists only users whose
>> default
>> shell is bash. Or, at least users whose default shell is tcsh are not
>> listed at all, and if they attempt to log in just by giving their UNIX
>> username, their X11 session "crashes", meaning that after attempting to
>> start, it just trows one back to GUI/X11 login screen.
>>
>> I really do not want to start this shell vs that shell flame war
>> (especially that I myself prefer not tcsh but sh and/or bash for
>> scripting...). But I respect my user's freedom of choosing default
>> shell,
>> so this is really big issue IMHO.
>>
>> I just wonder: does RedHat (CentOS's upstream vendor) dislike and is
>> willing to eradicate all shells except for bash, or what I see is just
>> my
>> own pilot's error?
>>
>
> Just for future advise.. for someone who says they don't want to start
> a flamewar.. you worded that pretty much like you wanted to start a
> flame war.

Thanks a lot! Well, not flamewar about different shells, but some acid
about something that broke on enterprise kind of system somewhere in the
middle of its life cycle. Well, "nothing changed" apart from installation
of a bunch of updates. This and another system which misbehaved were two
or so months behind on updates - my fault - and were fully updated in one
go. And, of course, I still don't exclude pilot error ;-)

Of course, being not native English speaker, I didn't manage to express my
bitterness about system, not shells whichever were mentioned. My
alopogies.

>
> This was simple to test.
>
> 1. I installed RHEL-7 in a virtual machine.
> 2. I created an account with its shell /bin/tcsh [useradd ssmoogen -s
> /bin/tcsh ]
> 3. I went to the login screen. There was an ssmoogen there
> 4. I logged in as ssmoogen. I got a GNOME desktop
> 5. I opened a terminal and my shell was tcsh.
>
> That took me 10 minutes. Due to this I am going to say that there is
> something wrong with other parts of the start up environment from what
> the shell is listed as in /etc/passwd, if the user has specific
> startup scripts .xsession items or some similar problem based on
> 'shell cruft'. People who work on many different systems have to
> regularly add exceptions and special cases or unadd them when they
> find stuff breaks.

Thanks a lot! I will go thoroughly through user in question ~/.cshrc.
Indeed, freshly created user with tcsh as default shell does successfully
log in and X11 does not crash on him. One pilot error: I didn't check that
before bugging everybody...

> I would also check to see if there is a post
> configuration setup which changed /etc/shells on the system. Another
> common problem is that the shell or startsups are looking for
> /usr/local/bin/tcsh which doesn't exist.

Quick test with creating user with shell /bin/tcsh makes user successfully
shown on GUI login. However, changing that user's shell to /usr/bin/tcsh
makes user disappear from GUI login. And the second (/usr/bin/tcsh) in
actual location of tcsh binary, whereas /bin/tcsh involves symlink /bin
--> /usr/bin ... My other playing around with making different default
user shells didn't always yield reproducible results... so I'll postpone
anything conclusive till later. But looking into /etc/shells (Thanks
again!!) shows that only bash gets unique privileged treatment, namely



>
> Red Hat has a lot of different developers using pretty much every
> shell that is shipped in RHEL and some which aren't even in Fedora.
> The developers also use all kinds of different desktops and software..
> while this doesn't mean bugs won't happen.. it does mean that if 'Red
> Hat' was out to eradicate other shells, there would be posts on every
> hacker site from Red Hat employees who wouldn't put up with it.
>
>
>
>> Thanks in advance for all your answers.
>>
>> 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
>> https://lists.centos.org/mailman/listinfo/centos
>
>
>
> --
> Stephen J Smoogen.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



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

Re: [CentOS] GUI/X11 login and shells other than bash?

[Stephen John Smoogen]

On 15 December 2017 at 17:39, Valeri Galtsev  wrote:


>> 4. I logged in as ssmoogen. I got a GNOME desktop
>> 5. I opened a terminal and my shell was tcsh.
>>
>> That took me 10 minutes. Due to this I am going to say that there is
>> something wrong with other parts of the start up environment from what
>> the shell is listed as in /etc/passwd, if the user has specific
>> startup scripts .xsession items or some similar problem based on
>> 'shell cruft'. People who work on many different systems have to
>> regularly add exceptions and special cases or unadd them when they
>> find stuff breaks.
>
> Thanks a lot! I will go thoroughly through user in question ~/.cshrc.
> Indeed, freshly created user with tcsh as default shell does successfully
> log in and X11 does not crash on him. One pilot error: I didn't check that
> before bugging everybody...
>
>> I would also check to see if there is a post
>> configuration setup which changed /etc/shells on the system. Another
>> common problem is that the shell or startsups are looking for
>> /usr/local/bin/tcsh which doesn't exist.
>
> Quick test with creating user with shell /bin/tcsh makes user successfully
> shown on GUI login. However, changing that user's shell to /usr/bin/tcsh
> makes user disappear from GUI login. And the second (/usr/bin/tcsh) in
> actual location of tcsh binary, whereas /bin/tcsh involves symlink /bin
> --> /usr/bin ... My other playing around with making different default
> user shells didn't always yield reproducible results... so I'll postpone
> anything conclusive till later. But looking into /etc/shells (Thanks
> again!!) shows that only bash gets unique privileged treatment, namely
>
>

I think that is mainly from /usr/bin/bash showing up in scripts which
check to see if they are allowed to be run by checking /etc/shells but
I am not 100% sure on that. None of the users I see created by the
built in tools give /usr/bin/bash as default shell but there are mods
for apache and other tools which use /etc/shell the see if user
scripts can run as such. Because most scripts are written in sh versus
csh this is a more likely scenario to run into. [I am not sure even
BSD systems write many scripts in csh.. I have only seen one major
script since 1992 that was in csh.] However in academia.. tcsh is
still used quite a lot from professors and their students who learned
on old BSD so it may be more common to have /usr/bin/csh

I wonder if adding /usr/bin/tcsh fixes the gnome account problem for you.



>
>>
>> Red Hat has a lot of different developers using pretty much every
>> shell that is shipped in RHEL and some which aren't even in Fedora.
>> The developers also use all kinds of different desktops and software..
>> while this doesn't mean bugs won't happen.. it does mean that if 'Red
>> Hat' was out to eradicate other shells, there would be posts on every
>> hacker site from Red Hat employees who wouldn't put up with it.
>>
>>
>>
>>> Thanks in advance for all your answers.
>>>
>>> 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
>>> https://lists.centos.org/mailman/listinfo/centos
>>
>>
>>
>> --
>> Stephen J Smoogen.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> 
> 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
> https://lists.centos.org/mailman/listinfo/centos



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