My node app is deployed with a single `myapp.service` file thanks to systemd:
[Service]
ExecStart=/usr/local/bin/node --harmony /var/www/myapp/server.js
Restart=always
User=nobody
Group=nobody
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
cp myapp.service /etc/systemd/system
systemctl enable myapp.service
systemctl start myapp.service
- Not restarting repeatedly if the app is bouncing up and down.
- I can see how it goes with `journalctl` which reads journald messages, and those messages come from a source called `myapp` rather than the old ancient syslog facilities (local0, uucp, lpd) which everyone just ignored in favour of grepping.
That said I'm somewhat on the fence about firewalld in a server context - the zones are really designed around mobile computing use-cases, and I'm not a fan of xml as a configuration language.
I installed it on VirtualBox (using a Windows host pc). I must say, my first impressions are that this is a very nice release.
They implemented the same new installer from Fedora, which I really like. It makes for 2 clicks (Language and Keyboard) and then it's installing in the background while you can setup your passwords and accounts. This makes for a very fast install.
The system just seems to feel "faster". I know that is completely objective, but mind you, I did not have the VirtualBox Guest Tools installed on the VM, and it still felt "native". I'm not sure what about it specifically feels faster, just everything I guess... especially booting.
eth0 was set to "ONBOOT=no" by default, which tripped me up for a half second (since all previous releases came with all adapters up). A quick config change and restart the network service, and up and running. I was surprised there was already update packages available, including a kernel update.
VirtualBox did not want to install it's Guest Additions/Tools on the VM, due to some change with "numa", from my understanding it's memory allocation related (could be wrong). In any event, I got the "struct mm_struct has no member named numa_next_reset" error.
Some digging around and I located this patch: https://www.virtualbox.org/ticket/12638
Applied it to the VirtualBox src once it unpacked itself to the /opt directory. After the patch, the Virtualbox Tools compile ok and installed.
I have a lot more playing around to do this evening... but so far, happy to say, this is shaping up to be a great release.
(trick question, you cannot, use old init.d scripts)
[Unit]
Description=The Apache HTTP Server
After=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=/usr/sbin/httpd $OPTIONS -k graceful-stop
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
I wouldn't expect to go to Windows' list of services, right click one and run arbitrary commands either.
# /etc/init.d/mysqld configtest
Usage: /etc/init.d/mysqld {start|stop|status|restart|condrestart|try-restart|reload|force-reload}
# /etc/init.d/mysqld graceful
Usage: /etc/init.d/mysqld {start|stop|status|restart|condrestart|try-restart|reload|force-reload}but even in your example, condrestart, try-restart, those aren't supported by pure systemd scripts - however if you were using the init.d version you could do the easy-to-remember/type service mysqld condrestart
Fortunately with 7.0 you can keep using the old init.d scripts and custom commands, hopefully that will never go away with any of the later 7.x versions (I don't see why).
What's 'graceful'? A particular signal?
This is what many people view un-unix like, a big dependency, that can't be replaced in the chain. The systemd developers also develop udev (which actually builds out of the same source tree as systemd), and there have been a few arguments about whether certain responsibilities are that of the kernel, or udev/userspace http://lwn.net/Articles/518942/, http://lwn.net/Articles/593676/. Systemd also touts its cgroup usage, though they view that they should be the only user of cgroups, since they are in a spot to "manage things properly" (which is partially true). (Some services have also started relying on systemd's cgroups to clean up orphan processes, which is bad for other init systems that don't do this).
So no one really hates how systemd works, just how its managed, and what it aims to do. If it were a simple init system and service manager, there would probably have been no arguments.
And they're absolutely correct. There can only be one cgroups manager on the system. cgmanager isn't finished, either.
>As an example, Gnome now uses parts of systemd for session management (replacing consoleskit, and others). While there are workarounds, this means no one can really use any other init system besides systemd, or things won't work correctly.
Gnome requires logind, which is the successor to consolekit. Gnome has repeatedly stated that they're willing to work with the BSDs et al with workarounds. You can either use the old logind, which doesn't require systemd as PID1 (due to cgroups management changes) or you can develop your own replacement to logind, one that doesn't require systemd as PID1.
People criticize these decisions, but they have no suggestions on how to fix it and, for the most part, they have no inkling of why there's a requirement.
2) MAH FREEDOMS!
There are technical reasons people don't like systemd that are valid, but usually the die hard anti-systemd people boil down to hating Lennart Poettering and complaining about how the US Constitution must some where say they never have to use systemd.
There are some valid concerns (big scope, bloat, feature creep, etc) but they really haven't come to fruition, although are still valid concerns.
At the end of the day, without much effort or trouble of switching to systemd from OpenRC, my system boots faster, which is great.
I can't imagine why this didn't get more traction.
systemd's declarative unit file syntax is easier to reason with, but comes at the expense of having to memorize a ton of options and being fundamentally dependent on the toolbox provided to you by systemd, since you can't code your way out of unconventional corner cases as easily.
The unit file syntax isn't the reason people complain, though.
It's hard to keep Centos Update to date with latest software IMHO.
I'm not an SysAdmin but I think the idea of APT and YUM is same but why it's so hard/trouble to use YUM?
One of the core features of CentOS/RedHat/Scientific Linux/etc is their longterm support and package freeze (excluding critical security updates). If you are reliant on a different version of software from the default repositories (both newer or older) then you are encouraged to build and package them yourself. Additionally in the RedHat-derivative universe there is the EPEL package repository which contains a wider range of software and is kept more readily updated in addition to being maintained by the Fedora Project (essentially RedHat).
https://access.redhat.com/documentation/en-US/Red_Hat_Softwa...
As another approach to mitigating dependency hell, you might consider using Docker containers for your services.
It used to be from a "Prominent North American Enterprise Linux Vendor". Something changed at some point.
http://www.redhat.com/about/news/press-archive/2014/1/red-ha...
http://lists.centos.org/pipermail/centos-announce/2014-Janua...
The delay in releasing CentOS 6 and the delays in updates had me worried about the future of CentOS.
CentOS 6 only required biosdevname=0
yum install net-tools is also a must
I think I've spent the first dozen hours with centos 7.0 just trying to get it to behave more like 6.5
Having to remember to run a script every time I edit grub configuration is annoying as hell too.
grub2-mkconfig -o /boot/grub2/grub.cfg
Well. Dangit. Grumble grumble...
1) http://www.slac.stanford.edu/comp/unix/linux/install_RHEL6.h...
I used to do that too, but then I figured there's a constructive use I could give to my old desktops when any such system reaches the age of replacement - just max it out on RAM and declare it a "home server". Now I can run a Minecraft node for my kids on it - with 2GB of Java heap, no less.
I mean, my Raspberry Pi has more than 128 MB of RAM.
Lots of RAM - like chicken soup for your server.
There used to be a Fedora equivalent called febootstrap, but it looks like it's mutated a bit since then: http://people.redhat.com/~rjones/supermin/
You may be able to work around it that way.
Out of interest, what machine are you using CentOS 6 on? I find 128mb kinda tight - although I've recently found a VPS provider who's managed to get Debian Jessie working in 96!
I don't even know if they have an ARM port (maybe an ARM 64bit for those new hip low wattage ARM microservers).
But wow I cannot stand grub2, what a mess.
Just install elilo and enjoy having a system that actually works.
Up until today, CentOS 6.5 was the latest release... so I can start using CentOS 7 now and enjoy the benefits that RedHat introduced in RHEL 7. You can see that the delay before CentOS releases a community version of RHEL has been much improved in recent years in this Wikipedia chart[2].
Also, iirc, this is the first major CentOS release with the CentOS project more or less under RedHat's wing[3].
[1] http://www.redhat.com/about/news/press-archive/2014/6/red-ha...
[2] http://en.wikipedia.org/wiki/CentOS#Versioning_and_releases
[3] http://www.infoworld.com/t/linux/red-hat-stamps-its-influenc...
Release notes: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7
https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
I can see a bootstrapped company using CentOS, or a company running on angel/seed money. Once a company gets Series A funding though, you have to start wondering why they wouldn't upgrade to Red Hat. The message from the company basically is they'd prefer the sysadmin to spend their nights and weekends figuring out problems, instead of making a small payment for support service. This is the type of position you want to run, not walk from.
On a job interview, a good question for a sysadmin to ask an interviewer when they say "do you have any questions to ask me?", is, "Will I support any machines, operating systems or applications that are not under a vendor support contract?" Inevitably there will be one or two legacy machines or applications, but if you get a laundry list in response, run.
The problem with this, of course, was that I don't want to open a vendor ticket until I have something to give them to work on. A random program crashed? First I'd blame the programmer or some other issue, not a kernel bug. But that particular manager just wanted to pin everything on the vendors no matter what.
As an aside, since I've been supporting Linux systems for the last 1.5 decades, I've only had to call in OS vendor support twice -- once was to verify what I already new (clock skew due to a bad hardware timer chip), and another time to satisfy an app developer manager who wouldn't take responsibility for his team's code.
Actually, I should add something -- with Red Hat support, you also get access to a whole history of past case logs at access.redhat.com -- these are discoverable through a Google search, but to see the full solution you have to be logged in. And this has actually kept me from needing to call Red Hat on a number of occasions, so I guess this can count as using Red Hat's support indirectly. And their knowledge base is very well written, esp. when explaining the root cause of specific known past issues.
So... if there's a friday night problem, you'd prefer staff to just be hanging, chillin' at home, and then when pressed, say "we created a ticket with redhat, nothing more to do!" ?
Critical breakages should keep people working until stuff is fixed. If you want to also pay a bit extra and involve external support people, that's fine, but it's not a magic bullet that just 'fixes' everything. You've now got to account for time to manage working with external support staff, making sure you can get them in to the affected systems, etc.
As such, the only advantage RHEL probably offers next to support are slightly faster updates.
The code is 100% open source.
Also you may want things like their software collections (which have had a hard time making it into centos).
Cost can be a little much especially if you don't need support other than package updates.
Also workstation in the minimum if you are going to do any development as desktop doesn't come with dev tools as far as I remember.
There's quite a few mirrors with images. However, they do recommend torrenting the images:
http://lists.centos.org/pipermail/centos-announce/2014-July/...