Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CentOS 7 released on x86_64

lists.centos.org

Post reply on HN
Print view View original

101–110 of 123 posts

Re: CentOS 7 released on x86_64

#101

Post by dale-cooper »

vezzy-fnord wrote: post #85
tene wrote: post #67

Earlier quoted context omitted.

I just can't agree with your [2] as a problem. The actual problem (an assertion failure in systemd) was fixed, several alternative workarounds are provided in case the user can't or doesn't want to upgrade systemd immediately, and functionality changes about when and where and how to log were going on on the mailing list, as they should be, and the reporters were directed there politely, even after violent vitriolic…

There's also this: https://bugs.freedesktop.org/show_bug.cgi?id=73729 Their attitudes towards journal log corruption have been rather apathetic, as well, though I cannot find the particular bug report at the moment.

That discussion escalated quickly.. What i got from the thread is that systemd will only work with glibc, intentionally? If that's the case then it's kind of sad. Since systemd will become the standard glibc will be the only alternative.

Re: CentOS 7 released on x86_64

#102

Post by ldng »

beedogs wrote: post #74
mackal wrote: post #50

Earlier quoted context omitted.

I've never had issues with PulseAudio personally.

...said no one ever. The very first thing I used to do on any new Linux install (until most distros stopped including it) was to uninstall Pulse and all of its dependencies.

I'll say it too.

There is a lot of unfairness around PulseAudio. Sure, it had its share of bugs BUT so did Alsa. PulseAudio was pushing the envelope so crappy Alsa drivers showed they limits. Crappy sound chips too. But PA took most of the blame although it was not always it fault. It could have been handled differently, maybe.

Re: CentOS 7 released on x86_64

#103

Post by TallGuyShort »

derekp7 wrote: post #54
TallGuyShort wrote: post #44

Earlier quoted context omitted.

Perhaps it's what you're familiar with and the intended use case. I personally can't stand the way APT won't let you override certain behavior. RHEL / CentOS have always favored stability over being bleeding-edge, and in my experience EPEL provides enough newer software to make the system usable for most cases, although if you're wanting the latest frameworks, etc.. I can see that being incompatible with your needs.…

I think the third-party frameworks issue can be solved with LXC / Docker. If app x requires library y and supporting utility z, this can all be put into a container without having to update the OS's versions of y and z.

Although personally I've had more instances of running into an incompatibility with the older CentOS 5 kernel than with any of the libraries in the distribution - which LXC wouldn't be able to help with.

Re: CentOS 7 released on x86_64

#104

Post by ck2 »

Shish2k wrote: post #93
ck2 wrote: post #72

Earlier quoted context omitted.

How do you do "configtest" and "graceful" with systemd/systemctl (trick question, you cannot, use old init.d scripts)

How do you do "configtest" and "graceful" with old init.d scripts? # /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}

configtest and graceful are "commands" used by other scripts such as httpd (apache) and nginx scripts which can take alternate signals to do other actions

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).

Re: CentOS 7 released on x86_64

#105

Post by stevekemp »

voltagex_ wrote: post #68
sliverstorm wrote: post #20

Earlier quoted context omitted.

Oh, I know, but I've been happily using CentOS 6 on my 128MB box, and was looking forward to CentOS 7.

When I'm building tiny Debian images, I use debootstrap, which doesn't seem to use much RAM at all. 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…

Once upon the time I created "rinse" which is an RPM-using debootstrap-like tool.

I've handed that off now, but the project is still very much alive:

http://collab-maint.alioth.debian.org/rinse/

Re: CentOS 7 released on x86_64

#106

Post by ck2 »

scurvy wrote: post #84

Now there are 2 kernel boot parameters required to get old style "eth#" interface names. net.ifnames=0 and biosdevname=0 CentOS 6 only required biosdevname=0

Thank you for this! I was going crazy trying to figure out how to get "eth0" back. Works perfect.

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
I mean that is so natural and easy to remember, lol - I had to make "update-grub" (like debian) an alias for it

Re: CentOS 7 released on x86_64

#107

Post by heroprotagonist »

kureikain wrote: post #43

I always scare of CentOS/Fedora. Whenever I updated something, it will be very old packages. Leading to use 3rd repo, and without any kind of document, the next sysadmin will be in trouble. I used to install Gearman on Centos 5.9 and it was a nightmare: the original 3rd repo didn't have gearman and I have to use other repo which is complain about PHP-Common conflicting. Remi and webtactic did help at the end. It's ha…

Besides using third party repos, you can also use Red Hat Software Collections for the official Red Hat offering of more recent packages (requires RHN, not available for CentOS).

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.

Re: CentOS 7 released on x86_64

#108

Post by nailer »

ck2 wrote: post #72
nailer wrote: post #4

Woo. Have been using the RHEL 7 Amazon AMI images, and it's nice not to worry about shell scripts / custom supervisord stuff for your web services anymore. 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=productio…

How do you do "configtest" and "graceful" with systemd/systemctl (trick question, you cannot, use old init.d scripts)

I'm not a systemd expert, but for configtest, you could add a 'Config' parameter and patch systemd to record the hash of each config file at start time. From then on, all .services, ever, that supplied their Config would be able to do a configtest and condrestart. DRY.

What's 'graceful'? A particular signal?

Re: CentOS 7 released on x86_64

#109

Post by Alupis »

jfindley wrote: post #28
nailer wrote: post #4

Woo. Have been using the RHEL 7 Amazon AMI images, and it's nice not to worry about shell scripts / custom supervisord stuff for your web services anymore. 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=productio…

You could potentially register your application with firewalld to make the iptables part even more elegant - then the port would only be open when the service was running. 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 gave CentOS 7 a spin last night (been waiting for the release!).

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.

Re: CentOS 7 released on x86_64

#110

Post by maddev »

ldng wrote: post #102
beedogs wrote: post #74

Earlier quoted context omitted.

...said no one ever. The very first thing I used to do on any new Linux install (until most distros stopped including it) was to uninstall Pulse and all of its dependencies.

I'll say it too. There is a lot of unfairness around PulseAudio. Sure, it had its share of bugs BUT so did Alsa. PulseAudio was pushing the envelope so crappy Alsa drivers showed they limits. Crappy sound chips too. But PA took most of the blame although it was not always it fault. It could have been handled differently, maybe.

ALSA is a piece of CRAP so its easy to compare with.

OSSv4 was the last sane thing in the linux audio department. :(

Post reply on HN