Re: [CentOS] The future of centos
Le 04/04/2015 03:01, Francis Gerund a écrit : Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this. Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos. Can you read between the lines? In this case, it isn't very hard to do, IMHO. community.redhat.com/centos-faq Yes, I already read this last June, when RedHat announced they had recruited CentOS main developpers. I don't see anything new here, or at least no change since this time. So, nothing new concerning the future of CentOS. Could you elaborate what you read between the lines there ? Alain ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On 04/04/15 02:40, Digimer wrote: On 03/04/15 09:39 PM, Always Learning wrote: On Fri, 2015-04-03 at 21:27 -0400, Digimer wrote: Being on CentOS, it is then trivial for these companies to switch the RHEL proper. Not if Centos and RHEL become too incompatible. Exactly why I believe it will not come to be. SIGs/variants may, but CentOS base will stay very close. It would be very stupid of RH to do otherwise. Exactly, the core distro stays where it is - we add layered and enhanced options with low barriers to entry around it. yum install centos-release-gluster yum install gluster. makes for a much easier gluster onramp ( or ceph or openafs ). If you look at the projects we interface with, it will be clear that this is all in the interest of the regular established existing CentOS userbase - eg. ci.centos.org now hosts the integration testing for libvirt upstream ( I suspect most people will agree that libvirt is something we all care about deeply ). Other projects I am working with to have them come test with CentOS are : OpenStack, theforeman, libguestfs, mariadb, postgresql etc ( and we welcome others a well). Now if you look at the SIGs coming up and delivering content - it should again be pretty clear what sort of content we are facilitating here. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 122, Issue 3
Send CentOS-announce mailing list submissions to centos-annou...@centos.org To subscribe or unsubscribe via the World Wide Web, visit http://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. Infra outage : bugs.centos.org (Fabian Arrotin) -- Message: 1 Date: Sat, 04 Apr 2015 12:01:35 +0200 From: Fabian Arrotin arr...@centos.org To: centos-annou...@centos.org Subject: [CentOS-announce] Infra outage : bugs.centos.org Message-ID: 551fb67f.9040...@centos.org Content-Type: text/plain; charset=utf-8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to a network routing issue happening outside of our infra, we have decided to migrate the CentOS bug tracker system (aka bugs.centos.org) to a new node today. Yesterday, around 2PM UTC, the company hosting the bugs.centos.org suffered from network connectivity loss (whole subnet not being routed/announced on bgp, etc ..). We've exchanged several phone calls to have an ETA, but it seems it was impossible to get any estimate. So, we decided to move the service to another node. (and service is now active). We had to restore the last good backup from that node, before machine was unreachable, so that means that we've lost some bug reports, and/or modified status/comments in the bug tracker. We're sorry for the inconvenience. on behalf of the Infra team, - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUftn8ACgkQnVkHo1a+xU5K9QCfd+7l8ZE3e5+0SkJRlcxOeIe4 qtUAn1KY0zRuXfQzyWBvMbnV4CAspwwc =ySbp -END PGP SIGNATURE- -- ___ CentOS-announce mailing list centos-annou...@centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 122, Issue 3 *** ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS-announce] Infra outage : bugs.centos.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to a network routing issue happening outside of our infra, we have decided to migrate the CentOS bug tracker system (aka bugs.centos.org) to a new node today. Yesterday, around 2PM UTC, the company hosting the bugs.centos.org suffered from network connectivity loss (whole subnet not being routed/announced on bgp, etc ..). We've exchanged several phone calls to have an ETA, but it seems it was impossible to get any estimate. So, we decided to move the service to another node. (and service is now active). We had to restore the last good backup from that node, before machine was unreachable, so that means that we've lost some bug reports, and/or modified status/comments in the bug tracker. We're sorry for the inconvenience. on behalf of the Infra team, - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUftn8ACgkQnVkHo1a+xU5K9QCfd+7l8ZE3e5+0SkJRlcxOeIe4 qtUAn1KY0zRuXfQzyWBvMbnV4CAspwwc =ySbp -END PGP SIGNATURE- ___ CentOS-announce mailing list CentOS-announce@centos.org http://lists.centos.org/mailman/listinfo/centos-announce
Re: [CentOS] systemctl (again)
Thats wierd. I've never had any problem with systemctl or systemd like that.
Do you have your service file in the right place with the right
permissions. here is the httpd service file as a reference.
[centos@ipa ~]$ ls /usr/lib/systemd/system/httpd.service -l
-rw-r--r--. 1 root root 694 Mar 12 14:57
/usr/lib/systemd/system/httpd.service
[centos@ipa ~]$ cat /usr/lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
On 4 April 2015 at 00:07, J Martin Rushton martinrushto...@btinternet.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yet more information:
As a test I moved the link
/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service into
/etc/systemd/user and reran systemctl daemon-reload. I then rebooted.
# ls -l /etc/systemd/user
total 4
lrwxrwxrwx. 1 root root 41 Jul 27 2014
dbus-org.fedoraproject.FirewallD1.service -
/usr/lib/systemd/system/firewalld.service
-rwxr-x---. 1 root root 246 Apr 3 21:21 timidity.service
# systemctl status dbus-org.fedoraproject.FirewallD1.service
dbus-org.fedoraproject.FirewallD1.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
# systemctl status timidity
timidity.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
So it's starting to look like a distro problem. Next I moved both the
Firewall service link and the timidity service file into
/etc/systemd/system:
# systemctl daemon-reload
# echo $?
0
and rebooted.
# systemctl status dbus-org.fedoraproject.FirewallD1.service
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service;
enabled)
Active: active (running) since Fri 2015-04-03 22:50:50 ...
Main PID: 785 (firewalld)
CGroup: /system.slice/firewalld.service
└─785 /usr/bin/python -Es /usr/sbin/firewalld ...
... Starting firewalld - dynamic firewall daemon...
... Started firewalld - dynamic firewall daemon.
# systemctl status timidity
timidity.service - timidity daemon
Loaded: loaded (/etc/systemd/system/timidity.service; static)
Active: inactive (dead)
Which is progress, but where to I'm not sure.
# ls -ld system user
drwxr-xr-x. 14 root root 4096 Apr 3 22:48 system
drwxr-xr-x. 2 root root 4096 Apr 3 22:48 user
# getfacl system user
# file: system
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
# file: user
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
Clearly there is a problem with my assumption about the default
settings. systemd appears not to read the user directory without
modification.
Trying to enable it leads to:
# systemctl enable timidity
The unit files have no [Install] section. They are not meant to
be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from
another unit's .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other
unit which has a requirement dependency on it.
3) A unit may be started when needed via activation (socket,
path, timer, D-Bus, udev, scripted systemctl call, ...).
Ah well, bed time. I'll tussle with Poettering's logic in the morning.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVHw8xAAoJEAF3yXsqtyBlieQP/3to6d4gqWZ1HQkTvwKwgSBf
Mg3GM6R+10E8skhHEuwAe8uX3ZznbO4F7NOMy3yRBSrL+y/fu6+U8To7T6wLvGKC
kFbdCbWradLP31clWzVjJYVVYIUXTVpMC6u59L5IFbYzIB//KShYC7NxDAtQ17qG
sbi82BuJRlXgF44cPnkv1LVX8OajUa6d2bppwrpZFNFQyAl3OUa7KY8rqe03kvWm
AxAXtHB/E72rHGG7RpdvdwkOJ4FEyxMjh1rzilVBmpuZPLGzfjJhX5ColKvmq34N
pABaBSFZeBQw/yk0KRt1eff/CBPR7pMTinxJPKuoVhbUXfJQ9yNcgXcWUg/R23+9
DfJBYwSCAYqvdKwKx7V/1kuQD/INvQiO3NtCc9Ck4cPj1b6udCjsImof07smy7jn
xe4q0mh4u7bx76gQQAq/4IQBBp5O8KkjK5oHt4gU2psqFLlSzvRen+fnqsDH2LaN
HvjOAWlxS40a5+GAcXkIk9qG9kzAV6lyNvG/lPrSQHyeitjGwClAJTwHBfWI7l0e
NuW216klW6VZP6Wm35nEAL7EZV4ADzLH2pqsOxB8dR7KdHAVq1Wwxe5XTi8cWJ8J
s4c2vT6uVpthpzGSbdEMoQla/DVp+h56vl2fFeY5Fww2MhODu7CmkUI2P7pvgKXy
icO1B4BtoxgV4dEXuHMK
=v3W6
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On 04/04/15 00:13, Always Learning wrote: Posted on behalf of Mark (m.r...@5-cent.us) who is currently experiencing technical difficulties with his Internet connection - On Fri, 2015-04-03 at 11:23 -0400, Lamar Owen wrote: I really think that if someone is actually interested in helping the project, rather than being a backseat driver and griping at every change Y'know, the whole thread with the naming, and the comments that it had been discussed, but only on the devel list, and the talk of an ambassador or whatever Couldn't some upcoming change like this have been mentioned in centos-announcements, and make sure it went to all the centos mailman lists? I am going to be on the move the next few days for personal reasons, and will catchup with the threads and comments as soon as i am able to. however, i want everyone to sit back and reflect on what they are doing here - make sure you are not creating noise for the sake of creating noise. As we all are well aware, there is a tendency on this list for people to get completely carried away and lose the ability to have a meaningful conversation. appreciate it, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
100% with Digimer here. I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS. All this energy should be put into contributing towards to the project, testing, helping out community. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Digimer li...@alteeve.ca To: CentOS mailing list centos@centos.org Sent: Saturday, 4 April, 2015 02:27:53 Subject: Re: [CentOS] The future of centos On 03/04/15 09:01 PM, Francis Gerund wrote: Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this. Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos. Can you read between the lines? In this case, it isn't very hard to do, IMHO. community.redhat.com/centos-faq How about you elaborate on your theory? Publicly, and I believe honestly, Red Hat wanted to ensure the long-term health of the CentOS project. Many companies, when starting out, use CentOS because of it's enterprise lineage and free-as-in-beer cost. Eventually, some of those companies will succeed and grow. Along the line, they will realize the value and ROI of switching to full enterprise support. Being on CentOS, it is then trivial for these companies to switch the RHEL proper. There is no grand conspiracy here. It is very much in Red Hat's interests to keep CentOS healthy and thriving. Will CentOS change over time? Yes, of course. Every project, company (and people) need to change and adapt, or else they will fade into irrelevance. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Sat, 2015-04-04 at 11:10 +0100, Karanbir Singh wrote:
Now if you look at the SIGs coming up and delivering content - it
should again be pretty clear what sort of content we are facilitating
here.
I think it inevitable that Red Hat will introduce some closed source
packages for the its paying customers, and thus hinder parasitic Oracle,
whilst continuing the development of the base system. This will probably
not affect the majority of 'standard' Centos users.
We have a proven reliable *free* operating system produced by The Centos
Team, just as good as RHEL although RH is preventing Centos certifying a
comparison. The comparison between RH and Centos versions is gradually
being separated, but never-the-less we retain a professional operating
system entirely free of licensing costs which satisfies our needs. And,
as a bonus, it is not Windoze.
If this had been explained at the beginning of the take-over of an
operating system clone by the originating source ('upstream') which
desired a de facto 'fork' to protect its commercial interests.
Back to work on RH Centos :-)
--
Regards,
Paul.
England, EU. Je suis Charlie.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Iptables config removed with 7.1 update
On Thu, 2015-04-02 at 22:42 -0600, Paul R. Ganci wrote: I had turned off firewalld and was using iptables when I originally installed CentOS 7.0. Two days ago I upgraded my CentOS 7.0 to 7.1. Everything seemed to be fine. Today I discovered that my iptables configuration was removed with the update. Has anyone else experienced this on doing upgrade? Literally the /etc/sysconfig/iptables is gone and the /etc/sysconfig/iptables-config is the blank template that comes with the distribution. This seems to me to be a serious bug with the upgrade. After the my mail server upgraded to 7.1 I have been unable to gain external access because of the firewall changes. I am working on trying to figure out what has happened. Looks like 7.1 has some bugs. Greg Ennis ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
On Apr 4, 2015 7:55 AM, J Martin Rushton martinrushto...@btinternet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Andrew. One more problem solved, as I discovered last thing yesterday there was a missing [Install]. Using your copy of the httpd service I cut-and-pasted it onto the end of the service file you'd given me earlier and at last was able to load the service. It wouldn't run, but at least it was some progress. I ran systemctl daemon-reload and rebooted. It is still failing though: # systemctl status timidity timidity.service - timidity daemon Loaded: loaded (/etc/systemd/system/timidity.service; enabled) Active: failed (Result: exit-code) since Sat ... Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=1/FAILURE) Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, status=0/SUCCESS) Main PID: 790 (code=exited, status=0/SUCCESS) snip The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file. If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails. Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from. --Pete ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks Andrew.
One more problem solved, as I discovered last thing yesterday there
was a missing [Install]. Using your copy of the httpd service I
cut-and-pasted it onto the end of the service file you'd given me
earlier and at last was able to load the service. It wouldn't run,
but at least it was some progress.
I ran systemctl daemon-reload and rebooted.
It is still failing though:
# systemctl status timidity
timidity.service - timidity daemon
Loaded: loaded (/etc/systemd/system/timidity.service; enabled)
Active: failed (Result: exit-code) since Sat ...
Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited,
status=1/FAILURE)
Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited,
status=0/SUCCESS)
Main PID: 790 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/timidity.service
...systemd[1]: Started timidity daemon.
...kill[955]: Usage:
...kill[955]: kill [options] pid|name [...]
(standard help message ommited)
...kill[955]: For more details see kill(1).
...systemd[1]: timidity.service: control process exited, code=exited
status=1
...systemd[1]: Unit timidity.service entered failed state.
Again, I'm wondering if systemd is not passing on the options when it
execs the daemon. This was, I think, the problem with the original
init script. There's certainly something weird going on:
Status code from sysctl start 0 (success)
Status code from ExecStart 0 (success)
Status code from Main PID 0 (success)
So I assume the daemon is being successfully started.
Status code from Active failed
Status code from systemd[1] control process exited,
code=exited status=1
Turning now to the location. I've been working in /etc/systemd/user,
and after that failed in /etc/systemd/system. Are you suggesting that
site customisations ought to be in /usr/lib/systemd/system? I would
normally regards /usr/lib as fairly sacrosanct. I don't have a copy
of the LSB to hand but I think that area is meant to normally be off
limits to sysadmins.
My next line of attack is to beef up the audit tral and see if I can
pick up the suspect exec. Any other suggestions welcome!
On 04/04/15 09:29, Andrew Holway wrote:
Thats wierd. I've never had any problem with systemctl or systemd
like that.
Do you have your service file in the right place with the right
permissions. here is the httpd service file as a reference.
[centos@ipa ~]$ ls /usr/lib/systemd/system/httpd.service -l
-rw-r--r--. 1 root root 694 Mar 12 14:57
/usr/lib/systemd/system/httpd.service
[centos@ipa ~]$ cat /usr/lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
On 4 April 2015 at 00:07, J Martin Rushton
martinrushto...@btinternet.com wrote:
Yet more information:
As a test I moved the link
/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service into
/etc/systemd/user and reran systemctl daemon-reload. I then
rebooted.
# ls -l /etc/systemd/user total 4 lrwxrwxrwx. 1 root root 41 Jul
27 2014 dbus-org.fedoraproject.FirewallD1.service -
/usr/lib/systemd/system/firewalld.service -rwxr-x---. 1 root root
246 Apr 3 21:21 timidity.service # systemctl status
dbus-org.fedoraproject.FirewallD1.service
dbus-org.fedoraproject.FirewallD1.service Loaded: not-found
(Reason: No such file or directory) Active: inactive (dead)
# systemctl status timidity timidity.service Loaded: not-found
(Reason: No such file or directory) Active: inactive (dead)
So it's starting to look like a distro problem. Next I moved both
the Firewall service link and the timidity service file into
/etc/systemd/system:
# systemctl daemon-reload # echo $? 0
and rebooted.
# systemctl status dbus-org.fedoraproject.FirewallD1.service
firewalld.service - firewalld - dynamic firewall daemon Loaded:
loaded (/usr/lib/systemd/system/firewalld.service; enabled) Active:
active (running) since Fri 2015-04-03 22:50:50 ... Main PID: 785
(firewalld) CGroup: /system.slice/firewalld.service └─785
/usr/bin/python -Es /usr/sbin/firewalld ...
... Starting firewalld - dynamic firewall daemon... ... Started
firewalld - dynamic firewall daemon. # systemctl status timidity
timidity.service - timidity daemon Loaded: loaded
(/etc/systemd/system/timidity.service; static) Active: inactive
(dead)
Which is progress, but where to I'm not sure.
# ls -ld system user drwxr-xr-x. 14 root root 4096 Apr 3 22:48
Re: [CentOS] The future of centos
On 04/04/2015 07:04 AM, Always Learning wrote: I think it inevitable that Red Hat will introduce some closed source packages for the its paying customers, ... For the sake of perspective, even in the old Red Hat Linux boxed sets in 1997 this was true. There was a whole CD of closed source stuff that you got in the boxed set that was never available for download. Things like WordPerfect for Linux, for starters. Sybase ASE was in one of the boxed set's Linux Applications CDs (but I seem to remember it being a 'limited' or 'personal' edition). Harking back to 1998, here's what is on that CD for Red Hat Linux 5.2: [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$ ls -1 AIS Applix ARDI CASEMaker CodeForge Crosswinds Decosoft DigitalControls EST Fastlane Flame Herrin HKS InfoSpring JX KAI Knowledge Knox Multisoft NetWin NExS Perforce README REBOL RPMS SAFE Shpink SpectraLogic Stalker SuSE Sybase Take5 TRANS.TBL VariCAD Visual WGS WP [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$ This is also true for RHEL, and has been for quite a while. There is a whole 'Supplemental' disc that has packages for which there is no source freely available, although the number of packages on that disc is relatively small, most of it being IBM Java for the 7.1 supplemental server disc. So it is nothing new to have closed source value-add in the Red Hat ecosystem. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Sat, April 4, 2015 4:47 am, Karanbir Singh wrote: On 04/04/15 00:13, Always Learning wrote: Posted on behalf of Mark (m.r...@5-cent.us) who is currently experiencing technical difficulties with his Internet connection - On Fri, 2015-04-03 at 11:23 -0400, Lamar Owen wrote: I really think that if someone is actually interested in helping the project, rather than being a backseat driver and griping at every change Y'know, the whole thread with the naming, and the comments that it had been discussed, but only on the devel list, and the talk of an ambassador or whatever Couldn't some upcoming change like this have been mentioned in centos-announcements, and make sure it went to all the centos mailman lists? I am going to be on the move the next few days for personal reasons, and will catchup with the threads and comments as soon as i am able to. however, i want everyone to sit back and reflect on what they are doing here - make sure you are not creating noise for the sake of creating noise. As we all are well aware, there is a tendency on this list for people to get completely carried away and lose the ability to have a meaningful conversation. I will try to guess what upsets many people. I remember long ago one of sysadmins was explaining to his user what CentOS is: it is binary replica of RedHat Enterprise Linux. I hope, this doesn't offend anybody. That was reasonably true, and CentOS was immediately carrying same trust, reliability and respect in person's mind as RHEL does. (I remember my friend sysadmin whose machines run Debian was regenerating all keys and certificates after known flop when in Debian in random numbers generator significant portion of code was commented out for debugging and left like that in releases for years... A said then: what a good choice of system was the one I made: I never remember a flop like that made by RedHat). Now the change is happening (or already happened). CentOS grew out of being binary replica. Does it mean it became worse? By no means no! Does it mean it is what it was in the past and carries the same respect as RHEL has? No. But last doesn't matter much to rather big crowd of people who think about RHEL after their release 7 differently (some quite differently). All in all CentOS seems to become distribution though based on RHEL, still having a bunch of extra nice stuff. Great thing all in all. Those who are upset may follow their former experience. I remember we were running RehHat (remember free RedHat, which lasted until version 9? You can buy a boxed set of CDs at a cost of CDs.) Then RedHat stopped doing that and we switched to Fedora (pilot project running in front of RedHat Enterprise). Not for long, as you wouldn't like short life cycle of system for your machine. This last thing might have depleted the size of Fedora community, maybe in favor of CentOS. And it is a community effort that RedHat was always efficiently using to cook nice system on the basis of (and they were always extremely good in my recollection in following GNU license and releasing all source!). If my guess above is close to reality, then having CentOS as a pilot project running in front of RHEL will be very beneficial. (Not that Fedora outlived itself as such, it still is great project, but CentOS may be good addition in that respect). Again, all above is something I tried to speculate together just for my understanding of what I observe (and should be taken with a grain of salt, as neither my observations are good, nor my thinking is). Valeri PS I have to add the following in case someone recognizes me as one of CentOS public mirror maintainers. As such (a public mirror maintainer), no matter that some scepticism might sound in what I'm saying, I'll keep maintaining CentOS public mirror (and vault mirror). I will keep maintaining the mirrors as long as the mirror machine (hosting multitude of other mirrors) exists, which will be while I have a sysadmin position at this university. We have benefited from CentOS for quite some time, and maintaining public mirror forever is that little that we can do for the great project (and yes, many of our machines still run CentOS, and will for quite some time to come...) Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] video problem since 2015-04-01 update
Is there a way in Centos 7 to boot into an alternate video setup? Some distributions have an option to boot into something called VESA (or something similar). Something that might not have the fanciest features, but more likely to at least just work. On Fri, Apr 3, 2015 at 8:58 PM, Francis Gerund ranr...@gmail.com wrote: Updated the kernel as suggested to 3.19, did not solve problem. Unbelievable! Oh, well . . . On Fri, Apr 3, 2015 at 8:13 PM, Francis Gerund ranr...@gmail.com wrote: Okay, thanks to all who took the time to reply. What a shame; I hadn't planned on spending Easter weekend learning to do kernel upgrades, but . . . here it goes. On Fri, Apr 3, 2015 at 5:59 PM, Ned Slider n...@unixmail.co.uk wrote: On 03/04/15 20:41, Francis Gerund wrote: Well, it could be the same, but the bug report does seem to refer to the bug being in kernel series 3.18. I am just using whatever 3.10 series kernel comes standard with Centos 7.x. Well, the CentOS kernel is a 3.10 kernel in name (or number) only. Red Hat backport much stuff from later kernels, and in this case that includes much broken code for the Intel i915 driver. The code is broken from around 3.15 and still not completely fixed in the current 4.0-rc6 code base. Updating to a newer kernel, and hence a newer i915 driver, may or may not help, but it doesn't hurt to try. I don't know anything about bug reports, and I an not familiar with swapping out kernels in Centos. BTW, is El Repo another name for the EPEL repository? No, they are two completely separate repositories: http://wiki.centos.org/AdditionalResources/Repositories On Fri, Apr 3, 2015 at 1:07 PM, Akemi Yagi amy...@gmail.com wrote: On Fri, Apr 3, 2015 at 10:30 AM, Francis Gerund ranr...@gmail.com wrote: Hello! No updates for days until 2015-04-01. Then presented with huge steaming pile of updates all at once, apparently related to Centos 7.1 release. After reboot, there is a problem with the video. It seems to flicker when the mouse pointer touches the screen edges. Also, sometimes when viewing pages in Firefox, the window becomes partially covered with horizontal black lines. During reboots, before the login screen appears, there are quickly disappearing messages seeming to include references to drm:9 and some sort of underrun. In the terminal window, I get a message: ABRT has detected 3 problem(s). For more info run: abrt-cli list --since 1428078184 When I do that, I get: id (blah, blah) reason: WARNING: at drivers/gpu/drm/i915/intel_display.c:869 intel_wait_for_vblank+0x211/0x220 [i915]() time: Fri 03 Apr 2015 11:41:49 AM CDT cmdline:BOOT_IMAGE=/vmlinuz-3.10.0-229.1.2.el7.x86_64 root=UUID=(blah, blah) ro vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8 count: 1 Directory: /var/tmp/abrt/oops-2015-04-03-11:41:49-590-0 Does this kernel.org bug look similar to yours? https://bugzilla.kernel.org/show_bug.cgi?id=86771 I suggest you try kernel-ml from ELRepo and see if that fixes the issue. Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On 04/04/2015 06:12 AM, Nux! wrote: 100% with Digimer here. I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS. All this energy should be put into contributing towards to the project, testing, helping out community. Lucian Agreed, and I want to thank you specifically for the nux dextop repo, which is in my standard installed repo set for EL6 and EL7. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Fri, Apr 3, 2015 at 12:19 PM, Always Learning cen...@u64.u22.net wrote: Will Centos versions eventually become incompatible, partially or wholly, with its parent's RHEL versions ? I can understand why that would be commercially advantageous to RH. I think it would be commercially advantageous if they did just the opposite - that is, make it so you could run exactly he same product on all of your machines and pay for support on the ones where you need support. I think that is the way Oracle is handling it. And their download approach makes it pretty clear that you are getting 7.1. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Some subscribers posts to the list ending up in Gmail spam
On 04/04/2015 09:59 AM, Andrew Holway wrote: Did we work out the technical reason why some users that post to the list are getting dumped into gmail spam? Ta, Andrew ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos It is most probably due to the various issues around dmarc, dkim and mailing list servers for which there is currently no great solution to the problem. If, for example I look at the your message (in this case, the one I am responding to), I see the following: 1. The message has intact a dkim signature from gmail, so the Centos mailman server is not stripping the dkim sig from the original sender, which recent versions of mailman can be configured to do. 2. The CentOS mailman server adds its own footer, changing the checksum of the message, so the dkim signature is no longer valid, therefore when any receiving mail server checks the DKIM sig it fails as it did with my own mailserver. 3. The centos server does NOT add its own DKIM sig and appears to have no DMARC record in the DNS (dig txt _dmarc.centos.org.) These are not necessarily a good idea anyway for mail coming from a mailing list server because in order to add a DKIM sig the from of the message would have to be changed to n...@centos.org since the mailman server can't itself sign for a sender from another domain. I'm not suggesting that DKIM or DMARC are a good solution to anything, however several of the FREEMAIL providers do pay attention to these things, so the CentOS mailserver admin might want to consider having mailman strip existing DKIM sig's from the mail (or alternatively not adding a footer). You can check the mailman doc/mailing list for other relevent options for working around these problems. . I believe that if, in your gmail account, you keep marking as NOT SPAM any false positives it will send more of these messages to the right folder. There has been an abundance of discussions in the past about these issues on the various mailman, dmarc and dkim mailing lists as well as in many other places. This whole issue hit the fan early in 2014 when yahoo and aol changed their DMARC policy to reject incoming mail that failed the DMARC test. Gmail, however, does not enforce the reject in others DMARC policy, but instead sends the email to the spambox (gmail also may send email to the spambox if it has no DKIM signature at all). I found that when I added (valid) DKIM signatures and a DMARC record for my domains, recipient freemail users messages started going to their inbox instead of their spambox. Nataraj ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On 4/4/2015 8:10 PM, dE wrote: If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc... they just like to whine. -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On 04/04/15 07:16, Always Learning wrote: On Fri, 2015-04-03 at 21:30 -0400, Digimer wrote: If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS. It is the open-source way, and I am not being sarcastic. Then call it ROSIE, Red Hat Operating System Intentionally . I need a suitable word beginning with 'E' :-) Well, now everyone knows the future of Centos. If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (SOLVED)
On Apr 4, 2015, at 3:45 PM, J Martin Rushton martinrushto...@btinternet.com wrote: 2)/etc/systemd/user is borked in my version of CentOS: systemctl doesn't read files from there. It does. If you use systemctl --user. But you're not using the userspace systemd to run this, you're running the system systemd, so there's no reason to ever touch /etc/systemd/user/. It may be possible to do what you want with a 'systemd --user' process, but as you've described in another email, you don't want it running with your user session, you want it as a daemon. -- Jonathan Billings billi...@negate.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
On Apr 4, 2015, at 4:08 PM, J Martin Rushton martinrushto...@btinternet.com wrote: This is a quite messy though as you're running a 'system service' in the context of a regular user you were better off doing this within the user space as you started with. It's getting rather windozy though if proper background system stuff is moved into user space. Multiple definitions of the D: drive anyone? :-( And of course, that's not at all what running systemd user services is about. Its possible to have systemd start up a separate systemd process for each user, to manage user-based services (such as your example), but run outside of your login session, with all the resource management/cgroups and logging features you get with systemd. I'm not really thrilled with the service, though. Since it operates outside of user login sessions, anyone who uses homedirs that require network authentication (such as NFS w/ sec=krb5 or OpenAFS) can't use it at all, since it looks in ~user/.config/systemd/ for services. -- Jonathan Billings billi...@negate.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Sat, April 4, 2015 11:46 am, Andrew Holway wrote: In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company. http://otternetworks.de/tech/rhel-centos-brief/ Once you asked for comments, here it goes: You are saying: Currently is appears that there are two strong contenders for a Linux distribution. Ubuntu and Redhat Enterprise Linux/Centos. You seem to be overlooking Debian. Ubuntu (and many others) at some point were clones of Debian. One can argue Ubuntu stepped up (or aside) a lot since. Still... Just MHO. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company. http://otternetworks.de/tech/rhel-centos-brief/ I for one welcome our Redhat overlords. I think they will provide better governance which should give Centos better credibility as an Enterprise, community supported operating system. On 4 April 2015 at 17:17, Lamar Owen lo...@pari.edu wrote: On 04/04/2015 06:12 AM, Nux! wrote: 100% with Digimer here. I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS. All this energy should be put into contributing towards to the project, testing, helping out community. Lucian Agreed, and I want to thank you specifically for the nux dextop repo, which is in my standard installed repo set for EL6 and EL7. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote: 100% with Digimer here. snip All this energy should be put into contributing towards to the project, testing, helping out community. Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think. http://bugs.centos.org/view.php?id=7972 Crashes related to 6.6 update involving the way init is done and X is done seem, at least to me, serious enough to have warranted a look-see, at least, if there is still real concern for the (desktop?) community. Since I don't feel it's my place to tell others how to behave, this (lack of) response has me now looking for alternatives that are (maybe?) more reliable and responsive. Since I've transitioned to a user that just wants a reliable tool now, the 6.6 upgrade soured me big-time. Then having the bug report serve only to grow mold, rather than getting the (apparent) conflict twixt init, X, the (new?) init processes ... looked at is sealing my decision to find a more reliable desktop distribution. Been UNIX (programming and user) since 1978, Linux since some early Slackware distributions, CentOS since 4.x. Will now be looking for something staying truer to the original UNIX concepts but full-featured and stable - may not be available, but I've got to at least look. You know, something that doesn't bomb on a point release update because (inadequately tested/previewed and unnecessary/useless?) changes were thrown in. Add in the extra instance of Firefox that hogs a 6-core AMD processor (patch provided to the list earlier), stuff X-related running and trying to contact the free desktop org folks w/o any notification (shades of MS!), ... I can't speak for others, but changing much of anything in the init processes and having extra instances of application software started and running without user being ware (when these weren't so common in the past?) seems significant and my thinking would be to save those for better testing, possible RFCs, and major releases. But I'm not a developer any more and don't expect the rigor I used to apply still works in today's world. Lucian snip MHO, in (partial) ignorance, Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Some subscribers posts to the list ending up in Gmail spam
Did we work out the technical reason why some users that post to the list are getting dumped into gmail spam? Ta, Andrew ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Some subscribers posts to the list ending up in Gmail spam
I get that too. How do you turn this off? They could be using an email server that is on a blacklist. On Sat, Apr 4, 2015 at 11:59 AM, Andrew Holway andrew.hol...@gmail.com wrote: Did we work out the technical reason why some users that post to the list are getting dumped into gmail spam? Ta, Andrew ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- - Hal Wigoda Chicago ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
On 4 April 2015 at 18:40, Jonathan Billings billi...@negate.org wrote: On April 4, 2015 12:14:08 PM EDT, Pete Travis li...@petetravis.com wrote: On Apr 4, 2015 7:55 AM, J Martin Rushton martinrushto...@btinternet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Andrew. One more problem solved, as I discovered last thing yesterday there was a missing [Install]. Using your copy of the httpd service I cut-and-pasted it onto the end of the service file you'd given me earlier and at last was able to load the service. It wouldn't run, but at least it was some progress. I ran systemctl daemon-reload and rebooted. It is still failing though: # systemctl status timidity timidity.service - timidity daemon Loaded: loaded (/etc/systemd/system/timidity.service; enabled) Active: failed (Result: exit-code) since Sat ... Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=1/FAILURE) Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, status=0/SUCCESS) Main PID: 790 (code=exited, status=0/SUCCESS) snip The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file. If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails. Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from. --Pete ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Is $MAINPID defined in your pidfile? It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined. This would be better served as the following to accomplish the immediate goal: cat /etc/systemd/system/timidity.service EOF [Unit] Description=timidity daemon [Service] User=jmr Group=users WorkingDirectory=/home/jmr Type=forking ExecStart=/usr/bin/timidity -iAD EOF systemctl daemon-reload systemctl start timidity You don't need to define an ExecStop and the type of the service should be forking as you are daemonising it - simple if you didn't daemonise it (or skip type which has this as default). There is also no need to deal with the race condition mess that is a PID file with systemd as well... technically there is no need to mess with MAINPID in this scenario. This is a quite messy though as you're running a 'system service' in the context of a regular user you were better off doing this within the user space as you started with. The reason that failed for you before is that you were making calls to systemctl without the --user option so it was trying to act in the system context. However a google of timidity systemd has the arch wiki within the first few results that has good information which results in a technically much nicer solution. https://wiki.archlinux.org/index.php/Timidity#Daemon Note the --global option which makes it start on a per user basis when the session for that user starts. Also note they don't daemonise it as there is no real reason to with systemd controlling the process state. If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Fri, April 3, 2015 22:54, Always Learning wrote: On Fri, 2015-04-03 at 22:47 -0400, Digimer wrote: No, people are speculating about the future of CentOS. . . . The future is certain. To benefit from this free operating system, tolerate the RH control and desire to ensure Centos and RHEL are not exactly the same (including incompatible version numbers) or get another operating system. It is that simple. Happy Easter to everyone. . . . There remain ClearOS and Scientific Linux. But, I am in no hurry to make any decision at the present time. I am not at all on-board with the evil empire takeover interpretation of recent events. I do not believe this to be the case. However, the golden rule holds that whoever pays the gold makes the rules. I do not think this situation will prove any different in the long run. When a volunteer board becomes dominated by a single commercial entity who pays employees to volunteer the long-term results are decisions that tend to favour that entity over all members. I have seen this happen first hand and our firm no long belongs to that particular national organisation in consequence. This is an interesting situation from a philosophical POV though. What are the ethics of attempting to monetize the intellectual property of others? What are the ethics of attempting to make use of the benefits that arise from that monetizing effort without paying for them? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think. It appears that you are the only one to have encountered this bug. Within any project, open source or proprietary; problems are usually prioritized according to the severity of the bug and the number of users that it affects. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Sat, 2015-04-04 at 19:14 +0200, Andrew Holway wrote: Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think. It appears that you are the only one to have encountered this bug. Within any project, open source or proprietary; problems are usually prioritized according to the severity of the bug and the number of users that it affects. Yep. I may be the only one that happens to use this in the way I do. But then I would expect at least a change to closed status with a reason to be given, based on past behavior? Regardless, if one is given the ability to switch run levels via the use of telinit and the like, shouldn't one be able to rely on it operating properly? When one takes the time to run multiple tests demonstrating the problem, collect and make available the related files, post with if more is needed or something wasn't properly reported let me know, wouldn't one deserve at least a look-see and some sort of response or status change? That being in the contribute to the community spirit under discussion. The processes I go through that produced the bad results have been used by me since CentoS4.x, IIRC, and certainly through all of CentOS 5 and 6 prior to 6.6. BTW, in acknowledgment of the CentOS folks, I realize they try to be 100% compatible with RH, warts and all, so the occurrence of the problem is not really a CentOS group problem, per se, but a RH issue. Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
On April 4, 2015 12:14:08 PM EDT, Pete Travis li...@petetravis.com wrote: On Apr 4, 2015 7:55 AM, J Martin Rushton martinrushto...@btinternet.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Andrew. One more problem solved, as I discovered last thing yesterday there was a missing [Install]. Using your copy of the httpd service I cut-and-pasted it onto the end of the service file you'd given me earlier and at last was able to load the service. It wouldn't run, but at least it was some progress. I ran systemctl daemon-reload and rebooted. It is still failing though: # systemctl status timidity timidity.service - timidity daemon Loaded: loaded (/etc/systemd/system/timidity.service; enabled) Active: failed (Result: exit-code) since Sat ... Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=1/FAILURE) Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, status=0/SUCCESS) Main PID: 790 (code=exited, status=0/SUCCESS) snip The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file. If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails. Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from. --Pete ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Is $MAINPID defined in your pidfile? It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined. -- Jonathan Billings billi...@negate.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-es] Lentitud en acceso a discos en VM alojadas en IPLAN
Segun tu criterio ya les distes todas las pruebas posibles con captura de pantalla de comandos que debuggean o validan que por parte de ustedes el software NO esta causando el problema y con la intencion de que ellos traten de verificar si es problema de Hardware del Dedicado que afecte a los Virtuales o alguna configuracion que el mismo iPlan haya realizado al Dedicado y que igual afecte a los virtuales y aun asi NO te estan haciendo caso o lanzan evasibas. Yo te recomendaria empezaras a actuar de una forma mas rigorosa, porque al fin y alcabo iPlan es un proveedor, que para bien o para mal, si TU no te quejas y dejas pasar el incidente, los ingenieros simplemente tapan el suceso y sigue todo rodando como si nada. De modo que lo primero que deberias hacer es: 1- Contratar un servidor dedicado o virtual con otro proveedor. 2- Montar tu aplicacion y pasar las aplicaciones de debugeo (validacion). 3- Toma todas las pruebas con el nuevo proveedor. Teniendo ya todo favorable para ti, aqui es donde lanzas las cartas al aire, un *ultimatum* para iPlan, indicandoles que de no realizar las investigaciones y validaciones por su parte, cambiaras de proveedor por falta de responsabilidad y atencion. Copia el correo a todo mundo (soporte iPlan, gente de ventas iPlan, gerencia de tu empresa, etc...), y veras que en menos de 3 dias se pondran las pilas. De lo contrario, pues ya estarias con un nuevo proveedor. Saludos ! El 4 de abril de 2015, 0:40, Normando Hall nh...@unixlan.com.ar escribió: Buenas tardes amigos de la lista. Hace 3 años que tenemos varios servidores virtuales contratados en la empresa IPLAN en Argentina. Los mismos son gerenciados bajo VMWare TIER1 y TIER3, y las VM con Centos 6 64bits. Pues bien, hace unos meses notamos una baja pronunciada en el acceso a discos, porque nuestro sistema se ponía lento. Hemos hecho todas las verificaciones de rigor con: hdparm -t /dev/sda y por supuesto, verificar problemas de red, memoria, tamaño ocupado, siendo todos estos parámetros normales. Por supuesto, que se mantienen actualizados. Lo mas llamativo es que 3 VM que tenemos en dichaempresa comenzaron con el problema casi de forma simultánea, llegando a tasas tan bajas de 110KB/s de los normal que es casi 300MG/s. Por supuesto que hemos enviado capturas de pantalla de comandos, y dado todo tipo de acceso a nuestras VM para que los ingenieros de la plataforma pudieran comprobarlo con sus propios ojos. Ellos dicen que su plataforma funciona correctamente y que tienen además otra VM de pruebas montada tambien con Centos 6 64bits y que el acceso a disco es normal, por encima de los 300MB/S. Por supuesto que esto me irrita profundamente, porque no soy tan tonto de configurar tan mal no una, sino 3 máquina virtuales, y que sin hacerles nada comenzaron a reducir la velocidad de acceso a disco, pero estan insinuando que es un problema o alguna incompatibilidad de alguna aplicación de nuestro servidos lo que hace que ralentice el acceso a disco. He buscado y analizado todo tipo de documentación al respecto, y nada que salga realmente de lo normal, indica que algo puede ser responsable de tamaña reducción a punto de dejarlos casi inoperativos. Estoy realmente preocupado y comienzo a sospechar que no me están diciendo toda la verdad o que no saben lo suficiente. Le he llegado a proponer que me presten por unas horas su VM de testeo para que instalemos alli nuestra aplicación y verificar si es que realmente produce alguna incompatibilidad con VMWare que nos ralentice el acceso a discos. Estoy muy indignado, porque tampoco es poco lo que se paga. Las únicas aplicaciones instaladas son: MongoDB Percona y mantener actualizado el servidor con yum update. También hemos agregado los parámetros al kernel en el grub.conf elevator=noop y esas cosas, sin beneficio alguno. Alguien que pueda orientarme un poquito? Realmente estoy preocupado. Gracias y Felices Pascuas ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- M.S.I. Angel Haniel Cantu Jauregui. Celular: (011-52-1)-899-871-17-22 E-Mail: angel.ca...@sie-group.net Web: http://www.sie-group.net/ Cd. Reynosa Tamaulipas. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] video problem since 2015-04-01 update
On Sat, 2015-04-04 at 11:24 -0500, Francis Gerund wrote: Is there a way in Centos 7 to boot into an alternate video setup? Check the kernel parameters - ISTR long ago using a paramer to the kernel added to the grub boot line that had one of my machines go into VESA mode. ISTR some numbers after = that specied which VESA mode to use to get better resolution (more lines/screen). snip Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
You seem to be overlooking Debian. Ubuntu (and many others) at some point were clones of Debian. One can argue Ubuntu stepped up (or aside) a lot since. Still... This is very true. Maybe I should say yum based systems and apt based systems but I did not want to turn it into a technical article. Ill have a think about that. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-es] Lentitud en acceso a discos en VM alojadas en IPLAN
Que servicios tienes contratados con iPlan ? El 4 de abril de 2015, 13:16, angel jauregui darkdiabl...@gmail.com escribió: Segun tu criterio ya les distes todas las pruebas posibles con captura de pantalla de comandos que debuggean o validan que por parte de ustedes el software NO esta causando el problema y con la intencion de que ellos traten de verificar si es problema de Hardware del Dedicado que afecte a los Virtuales o alguna configuracion que el mismo iPlan haya realizado al Dedicado y que igual afecte a los virtuales y aun asi NO te estan haciendo caso o lanzan evasibas. Yo te recomendaria empezaras a actuar de una forma mas rigorosa, porque al fin y alcabo iPlan es un proveedor, que para bien o para mal, si TU no te quejas y dejas pasar el incidente, los ingenieros simplemente tapan el suceso y sigue todo rodando como si nada. De modo que lo primero que deberias hacer es: 1- Contratar un servidor dedicado o virtual con otro proveedor. 2- Montar tu aplicacion y pasar las aplicaciones de debugeo (validacion). 3- Toma todas las pruebas con el nuevo proveedor. Teniendo ya todo favorable para ti, aqui es donde lanzas las cartas al aire, un *ultimatum* para iPlan, indicandoles que de no realizar las investigaciones y validaciones por su parte, cambiaras de proveedor por falta de responsabilidad y atencion. Copia el correo a todo mundo (soporte iPlan, gente de ventas iPlan, gerencia de tu empresa, etc...), y veras que en menos de 3 dias se pondran las pilas. De lo contrario, pues ya estarias con un nuevo proveedor. Saludos ! El 4 de abril de 2015, 0:40, Normando Hall nh...@unixlan.com.ar escribió: Buenas tardes amigos de la lista. Hace 3 años que tenemos varios servidores virtuales contratados en la empresa IPLAN en Argentina. Los mismos son gerenciados bajo VMWare TIER1 y TIER3, y las VM con Centos 6 64bits. Pues bien, hace unos meses notamos una baja pronunciada en el acceso a discos, porque nuestro sistema se ponía lento. Hemos hecho todas las verificaciones de rigor con: hdparm -t /dev/sda y por supuesto, verificar problemas de red, memoria, tamaño ocupado, siendo todos estos parámetros normales. Por supuesto, que se mantienen actualizados. Lo mas llamativo es que 3 VM que tenemos en dichaempresa comenzaron con el problema casi de forma simultánea, llegando a tasas tan bajas de 110KB/s de los normal que es casi 300MG/s. Por supuesto que hemos enviado capturas de pantalla de comandos, y dado todo tipo de acceso a nuestras VM para que los ingenieros de la plataforma pudieran comprobarlo con sus propios ojos. Ellos dicen que su plataforma funciona correctamente y que tienen además otra VM de pruebas montada tambien con Centos 6 64bits y que el acceso a disco es normal, por encima de los 300MB/S. Por supuesto que esto me irrita profundamente, porque no soy tan tonto de configurar tan mal no una, sino 3 máquina virtuales, y que sin hacerles nada comenzaron a reducir la velocidad de acceso a disco, pero estan insinuando que es un problema o alguna incompatibilidad de alguna aplicación de nuestro servidos lo que hace que ralentice el acceso a disco. He buscado y analizado todo tipo de documentación al respecto, y nada que salga realmente de lo normal, indica que algo puede ser responsable de tamaña reducción a punto de dejarlos casi inoperativos. Estoy realmente preocupado y comienzo a sospechar que no me están diciendo toda la verdad o que no saben lo suficiente. Le he llegado a proponer que me presten por unas horas su VM de testeo para que instalemos alli nuestra aplicación y verificar si es que realmente produce alguna incompatibilidad con VMWare que nos ralentice el acceso a discos. Estoy muy indignado, porque tampoco es poco lo que se paga. Las únicas aplicaciones instaladas son: MongoDB Percona y mantener actualizado el servidor con yum update. También hemos agregado los parámetros al kernel en el grub.conf elevator=noop y esas cosas, sin beneficio alguno. Alguien que pueda orientarme un poquito? Realmente estoy preocupado. Gracias y Felices Pascuas ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- M.S.I. Angel Haniel Cantu Jauregui. Celular: (011-52-1)-899-871-17-22 E-Mail: angel.ca...@sie-group.net Web: http://www.sie-group.net/ Cd. Reynosa Tamaulipas. -- M.S.I. Angel Haniel Cantu Jauregui. Celular: (011-52-1)-899-871-17-22 E-Mail: angel.ca...@sie-group.net Web: http://www.sie-group.net/ Cd. Reynosa Tamaulipas. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
[CentOS] Access Problem after update to CentOS 7.1
Everyone, This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update. When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network. At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access. I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either. On one of the various reboots I tried to use the previous kernel before today's update, but there was no success. I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network. traceroute does not get to the mail server from outside the local network, but works fine inside the local network. Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server. Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update? Thank you for your help Greg Ennis ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (SOLVED)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 snip The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file. If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails. Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from. --Pete ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Is $MAINPID defined in your pidfile? It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined. Taking the above in order: 1) Yes the D does mean deamonise, as I mentioned previously. However it is not -i -A -D, but -i (interface is) A (Alsa, modified by) D (run as a deamon). Confusingly -D on its own refers to the drum channel. 2) -iA reads a file name as argument 1 and plays that. -iAD sets up sequencer ports to which an external program can write. 3) I've use Type=forking, with some success - see below. 4) pidfile wasn't being created. When I tried a startup the command hung for several minutes before returning with and error message. Also for the first time I was seeing output from timidity in messages. There was the usual clutch of SELinux messages, and although I am running permissive during test I created the policy modules to stop them. The status showed that systemd could not read the pidfile, then it claimed that timidity had timed out. Next timidity logged its successful startup mesages before systemd claimed to have failed to start it! Just out of interest I touched the pidfile and chmod'ed it 777. Suddenly it all worked! Systemd is spawning off timidity as user jmr, and timidity was not then able to create a file in /var/run. Failry obvious once you see it. So: Thanks to all who have helped. The principle lessons learnt seem to be: 1) Irrespective of the README in /etc/init.d, traditional init scripts will not work unless they fit some assumed and undocumented model. Do not waste time trying to use them. 2) /etc/systemd/user is borked in my version of CentOS: systemctl doesn't read files from there. 3) systemd must never be considered a simple replacement for init files, any attempt to use it in the same way is doomed to failure. You need to allow a few man-days to achieve success. Hopefully the time needed will reduce with experience, but I'll certainly not be upgrading any production servers until I'm forced to! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVID9WAAoJEAF3yXsqtyBlCw0P/1N9PpMZ8MYlVljW1qPd4A9z dblOiS/lerhx2GkqJZXbMCaJg1k5W54HUj8LztaNQhi4+B9GC2p2/PY1Gz3zAU4f rryfi6yVffeEAgw2FlrtJXCPn9pgjr6tr2JZH+2dM2zqEp4UYLpbPmjNBrrkAzsm najv0+05GTEMHKxMSQR8eKOfF02u7ccGJ68LvZUdJ2kGgCW9z7/lZcbCHQEc2NCS 06FiDTa2XmOk6i8RTpoIgpQ70ZGRZF7mP8IArRjvusmdvfGuwKoNgFdYiEtsVZIQ +vHGyq20/SG/XnW83OpJ4gmDnA7wdpMY+InqA+UuPpz+yaP75MM5qF+fcAqTOE2N 1kAbe1x/z5FhVzRg8v758+TPW6zGX09w/wglaXrEWLMrI2WjSHr1nbaAUsZm+OkK DYWcncf+Uj4XjNtL9UzdlmwlD2m3MgPVCAnoRQ8ncA4OMWkoll+vjkK1w6FngRo/ oMqnv+5g6gqDZVzc6VEBMObGTlizL74tiSiY1Fk0X5IiIH2CEMOzpGbXM1XMxh5C dYG6VMfen6KaISRJplUhq8LJLm0s/Ntkz77wRjnKDV3rRJsrZygLCgP/qFrDhwF8 HtoZ1IOpe4bfyeUTpduOz5AAZfHTZAOkxdKgBus4WuSMYOeqcZZgoR7WvKXL4PA8 ae5VpcKDuhghLqc8ZhRF =ZJ7p -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Mysterious ICMP timeout?
I am looking at these sorts of things as well: IN=eth0 OUT=eth1 SRC=129.250.200.121 DST=x.y.z.56 LEN=96 TOS=0x00 PREC=0x00 TTL=243 ID=32285 PROTO=ICMP TYPE=11 CODE=0 [SRC=x.y.z.56 DST=88.198.155.41 LEN=28 TOS=0x10 PREC=0x60 TTL=1 ID=1968 PROTO=UDP SPT=50131 DPT=6528 LEN=8 ] x.y.z.56 is a disused address in our netblock assignment. So whatever this is it is not legit. Does anyone recognize this? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemctl (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 snip This would be better served as the following to accomplish the immediate goal: cat /etc/systemd/system/timidity.service EOF [Unit] Description=timidity daemon [Service] User=jmr Group=users WorkingDirectory=/home/jmr Type=forking ExecStart=/usr/bin/timidity -iAD EOF systemctl daemon-reload systemctl start timidity You don't need to define an ExecStop and the type of the service should be forking as you are daemonising it - simple if you didn't daemonise it (or skip type which has this as default). There is also no need to deal with the race condition mess that is a PID file with systemd as well... technically there is no need to mess with MAINPID in this scenario. Points noted, I just took Andrew's file and changed the bare minimum. This is a quite messy though as you're running a 'system service' in the context of a regular user you were better off doing this within the user space as you started with. It's getting rather windozy though if proper background system stuff is moved into user space. Multiple definitions of the D: drive anyone? :-( Running as jmr is purely temporary, ideally I will create a timidity account for it, but for the present I just hacked Andrew's script to ensure the user/group/directory worked. The reason that failed for you before is that you were making calls to systemctl without the --user option so it was trying to act in the system context. Right, so user is user added code then. I assumed it was for site-local service files. However a google of timidity systemd has the arch wiki within the first few results that has good information which results in a technically much nicer solution. https://wiki.archlinux.org/index.php/Timidity#Daemon Thanks. Note the --global option which makes it start on a per user basis when the session for that user starts. Also note they don't daemonise it as there is no real reason to with systemd controlling the process state. It does need to be daemonised for frescobaldi to talk to it. The default (non-daemonised) way plays a file, if it is daemonised then it sets up ports to listen on. Hence the D modifier on the interface switch. I'll be honest though, when scanning for CentOS solutions I would routinely ignore ArchLinix. If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity No - I want it to start on boot and sit there like a good little daemon doing what it's told. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVIETbAAoJEAF3yXsqtyBluCMQALQmXr1j79saRLd3ulUD5L2W rF3dZ4GCLwWJMlCE9ITwJZE5afimlYWLBsQXRDbdw+EZ8xLrUNfmL4aiGW77LIoK cpkC1G/t3ZShUNjuu3pE4qxvBzSN3juLK8E9losaLKlpGaPlzqgVynZamyxX4kWp PHTQM1tyOh8lcZcjvb2nn81A0fWKHzzi9aXHDFsejsntFUd0QzsKkFOuXLHJNY/P yynX9fyiQ+1EvbjKL+i5ckMKMQg2ozdhTWzVtWqEZEHKu6ouaK+9+kiYM7k2Wy78 XrM/ccp/fEjMIcd8csaydg6N76oGrwGFhoIpuwbfk28wSiPX+RG1hmUN2zzXMNzw XN5scxJpBnpsKGB6WmUHw7ELK04r26orO1hPJW//4voYWyT5kIC2vg4d2viPuHgD zg7ogmUrTZAOa2Fh1dUXkYwLZyjT97hbteIj/hJBvpRJ42Gupnh5YDFmV29s1y8L OnFKy4iBSn0dEHspkHDaHBXEPOkqwcSf0p1gfGG7QTP2CdeUeKq8nj/BbMYRPDpy KsP7f6A0+xRTh+WTm74A1W4xGM9RIK58yoZ0+DcT318VvzjkVtYmbEILBjtz3Ag9 eiRWLLNiJvVn2tWBf5+p8YkELiJQknWk9bglYf9jmLzAegOm79QUwg53QGLMJ3Li fTqMaOEqRUyJF6XOSY+9 =yqOD -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
