|
|
#
?
Mar 12, 2015 06:07
|
|
|
|
| # ? May 31, 2024 20:11 |
|
|
systemd did not eat login, PAM, getty, mount, acpi, tcpwrapper, or audit, and I have no idea why that GIF says it did. But yes, I'm happy that it ate cron, init, and at, all of which are competing tools to simply start a thing (and possibly monitor it) at a specific time, and they all get it subtly wrong in different ways.
|
|
#
?
Mar 12, 2015 06:26
|
|
|
I do think that blog is idiotic. Almost nothing systemd is replacing is "user space" in a sense that systemd is not. systemd is not running in kernel space, and neither are its components. systemd is not re-defining or replacing userspace for the vast majority of users. Distro maintainers spend a lot of time making sure that basic services work out of the box. RHEL, for example, ships an NTP config which syncs to ?.rhel.pool.ntp.org. Why are clients running a full-blown NTP client? Is that necessary? Isn't SNTP enough? Can't systemd have a very small SNTP client to make sure that time sync is working and go from there? By default? And if you want a more complex environment, you can run your own whatever? Why does the RHCSA (or RHCE) need to cover all the services that gif is munching? Shouldn't admins only need to know about the services that actually matter in their environment, and have the rest of it "just work" without fiddling with a bunch of poo poo you should never need to worry about? That's where this is going. "Most distros will adopt systemd-networkd" is both true and misleading. They will adopt it. Because it's dramatically simpler and faster than networkmanager, wicd, or anything else (dhcp renew time ia about as fast as OSX's networking stack). It will not replace networkmanager. It's intended, like timed, for relatively simple user setups which don't need NetworkManager to negotiate ipsec or anything else. systemd is not "re-inventing network stacks from scratch". systemd is not intended to replace those software stacks for anything other than simple use cases. Why are distros talking about (or already) shipping full-blown DNS servers in caching mode to handle this? Do you need BIND or dnsmasq running just for DNS caching? Does it seem like using a sledgehammer to crack a nut? These aren't bad things. All of the knowledge you already have will still be valuable if you wind up in a situation where you need to configure your own $whatever. But it's not required anymore. "Use CoreOS" (at the bottom) is maybe the stupidest recommendation possible. There are few distros as close to systemd as CoreOS. CoreOS is arguably just the kernel, systemd, and docker. In a more general sense, systemd is the "Developers! Developers! Developers!" cry. For whatever complaints you may have about kdbus, dbus is a godsend, both in the session bus and system bus sense. I don't need to know any APIs to interact with anything. All I have to know is the dbus path and interface (which I can iterate and introspect in any language I want), and I can receive signals from some daemon about things changing without touching shm or relying on knowing the internals of some project I don't control and don't want to keep up with. As long as their public interface on a standard system stays the same, my code never needs to change. They can swap out the entire backend, and as long as the same methods are published on dbus, my stuff works. This is sanity, not insanity. This is good, not bad. sysvinit/init.d "works perfectly fine" for the 99% of people who don't really have to use it. The moment you start to interact with init.d or you need to write your own init script, it's not fine anymore. It's an antiquated, terrible shell-based system with vague analogues that sort of work in other languages, but probably don't do everything the distro scripts do anyway, so you end up writing shell and including their terrible crap. Then your daemon starts, and you need to use supervisord or something to make sure it doesn't crash. And maybe you need to have your daemon wait for the network to come up or fiddle with service ordering when somebody else changes their code, and you're stuck with a bunch of bugs that have to do with the platform interacting with a language (shell) that your application isn't written in, so now you've got logic in python or C or go and logic in the stupid shell script which starting your script and looking for vague exit codes to spit out a useful message to users instead of using the exception handling and logging you already have set up for your application to actually run. It's more compatible with everything. Because now developers, admins, users, and monkeys can write a 10 line service manifest which triggers any application running when the network comes up or a filesystem gets mounted or after foo starts but before bar starts. Using whatever language they want. Probably using the application they're already trying to start, in the same way as they've already been debugging it during development. And it'll appropriately trigger when you umount that filesystem or disconnect from the network or restart the service it's depending on. Do you know what a nightmare that is to do with sysvinit? systemd and all the bits are not more complexity. They are far, far less complexity. It's marginally more complex for admins (in a way that other UNIXes have already done, with solaris' *adm, etc), and hopefully invisible to end users other than faster startup and faster networking and time syncing out of the box and... Also, parallel startup is definitely still a thing. systemd is much faster than even upstart. If you think systemd isn't faster than sysvinit, I'd suggest that you haven't watched a system with sysvinit boot in a while. Sorry, I have strong opinions on the "systemd is more complex!" argument, as well as every other iffy argument against systemd. There are reasons to dislike systemd, much as there are reasons to dislike dracut. Like the difficulty of debugging problems with early boot (because it's not simple shell, and you can't unpack the initrd and add whatever you want to /init like you could with pre-dracut systems). systemd requires enabling a separate debug shell service to get one easily. Or journald's binary logging if you want to look at the journal with the disk in another system. Or that you may have to read manpages. But there aren't a lot of great arguments against it. Nobody is freezing at RHEL6 for enterprise any more than they froze on RHEL5 for enterprise. RHEL7 will start getting enterprise support (clearcase, etc) at 7.2, and businesses will start migrating at 7.3. Probably. We may be surprised, but the numbers so far look exactly like 5->6.
|
|
#
?
Mar 12, 2015 06:40
|
|
|
I disagree with what you said.
|
|
#
?
Mar 12, 2015 15:11
|
|
|
Suspicious Dish posted:Shouldn't be. What version are you on, and what are you trying to do with it? Just viewing the logs -- systemctl status foo or journalctl -u foo -b 0. Sometimes it happens instantly, sometimes it sits there thinking for 30 seconds or more before displaying anything. Version: code:Bhodi posted:Additional layers of complexity that add nothing to the system except for debugging headaches. It's initial push, start up items concurrently to boot faster, has been backed off and now you're left with little useful (at the moment, roadmaps are not features). It really brings nothing substantial to the table because it's harder, not easier, than what it's replacing. It's not compatible with poo poo and the devs clearly don't care about the end user. Personally, I find writing systemd unit files to be way easier (and harder to subtly gently caress up) than writing init scripts, and the standardized output of "systemctl status _" to be a lot more useful than whatever random crap "service _ status" spits out.
|
|
#
?
Mar 12, 2015 15:50
|
|
|
I stated up front my primary reason for hating it was that it's different, I don't know why you're getting all about objective facts in here. I've spent 20 years doing this poo poo and now you tell me I have to learn something completely new and different, just to keep using what I've been using. gently caress that. Let some bright-eyed bushy-tailed youth deal with the OS, I don't have the energy anymore. I just want poo poo to loving WORK when I type yum install, and I just know that forcing a change like this is going to cause some (many?) of the thousands upon thousands of RPMs maintainers' to throw their hands up in the air. It's going to introduce security vulns, bugs, and associated weirdness because it's a ton of code that hasn't seen trial under fire, and all that's going to make MY job harder because some fucker had a another bright idea and wouldn't leave well enough alone. MAYBE it'll all be worth it in a decade when it all settles out, because it's an objectively better system, but by then docker or the docker of 2020 will have popped up and linux is just "that thing" your service runs on and you never touch it because you don't need to and I'll be sitting on the beach sipping mimosas Bhodi fucked around with this message at 16:05 on Mar 12, 2015 |
|
#
?
Mar 12, 2015 16:02
|
|
|
poo poo should still work when you call type yum install. You can continue to use service and the sysinit scripts and hell, RHEL7 enables syslog redirection by default. The compatibility layers are still there.
|
|
#
?
Mar 12, 2015 16:07
|
|
|
I didn't mean literal yum install, it's an entirely different layer which I need to learn and understand to figure out what's going on when something breaks in the system. I mean honestly "systemctl" isn't much different than "chkconfig"; the biggest change I see right now as a user/admin is the binary logging, which is flat out retarded and I'll probably be disabling on any systems that I actually have to use it on because it breaks all of our logscraping code. Mostly I just want to yell at clouds like an old man, thanks for listening
|
|
#
?
Mar 12, 2015 16:14
|
|
|
Bhodi posted:Mostly I just want to yell at clouds like an old man, thanks for listening I can get behind this sentiment. 
|
|
#
?
Mar 12, 2015 16:20
|
|
|
chkconfig still works, at least. But yeah, the OS layer is changing a bit. It's changed in the past during your 20 years, and it's changing again. At least we're mostly trying to put wrappers around this stuff so it doesn't happen again (firewalld hiding the eventual iptables->nftables move, for instance). systemd won't break your log scraping code, because you can still log to syslog. Really trivially. Like, a one line change in the config. And journald log forwarding is objectively better than traditional syslog forwarding. I have to say that I find using "yum install" as an example kind of funny, since there are good odds you weren't even using yum until 5-6 years ago. Bhodi posted:I just know that forcing a change like this is going to cause some (many?) of the thousands upon thousands of RPMs maintainers' to throw their hands up in the air. It's going to introduce security vulns, bugs, and associated weirdness because it's a ton of code that hasn't seen trial under fire, and all that's going to make MY job harder because some fucker had a another bright idea and wouldn't leave well enough alone. It hasn't, though. Many of the "thousands upon thousands of RPMs" are maintained by RH employees and also present in Fedora anyway, so the move to systemd happened years ago. There are 3 sysvinit scripts left in Fedora in a base install. Maybe 4. There are almost no recognizable packages with sysvinit scripts left in the repositories. koji. ceph. Everything else has very sparse usage, or it's ${package}-sysvinit as legacy scripts, because ${package} already has systemd service files. There have been almost zero security vulnerabilities, bugs, or associated weirdness that I've seen or heard of. The "debug" karg spat with Linus is the big one. But because it's far less complex than sysvinit scripts, there are also likely to be far less bugs in the future. Plus, sysvinit still works! If some vendor doesn't feel like using systemd for whatever reason (probably AIX compatibility, since Solaris service manifests also require doing things a different way), they don't need to. /etc/init.d/something gets transparently mapped to something.service, and systemd manages it anyway. So they don't need to rewrite code and potentially introduce bugs (although, again, it'll probably be far less bugs, since whatever's happening in their "start" function is incredibly easy to move to a service manifest). I know it's change. And it's different. And you don't wanna learn new and different stuff anymore. But unsubstantiated gut feelings about introducing bugs and so forth which haven't been borne out by reality during the years-long systemd introduction phase seems to be the primary complaint. Especially from admins who don't really have to deal with the messy parts of service startup anyway and only have a vague idea of how systemd is different (and vastly easier) for the developers and maintainers who do. I'm not trying to be all argumentative, but  systemd is settled out now, and it's worth it now
|
|
#
?
Mar 12, 2015 16:47
|
|
|
You really want to piss people off? Just mention SeLinux  I like SeLinux a lot.
|
|
#
?
Mar 12, 2015 17:11
|
|
|
ratbert90 posted:You really want to piss people off? Just mention SeLinux Wow, and we were going to hire this guy....
|
|
#
?
Mar 12, 2015 17:21
|
|
|
I just installed CentOS on a new home server, first time using CentOS as a primary server. What is the best way to work with the firewall? Some sites use iptables, others use firewalld and I'm sure others have mentioned other ways. I just want to add a few simple rules, ignore apache, subsonic, etc.
|
|
#
?
Mar 12, 2015 18:01
|
|
|
Suspicious Dish posted:Wow, and we were going to hire this guy.... Hey, whats wrong with SeLinux? I understand it's not for everybody, and I mainly use it on servers; I don't think I have ever needed it in a embedded setting. But it's just a bunch of boolean values and you can use it to fine tune permission settings.  People sure do get upset over a tool.
FlapYoJacks fucked around with this message at 18:11 on Mar 12, 2015 |
|
#
?
Mar 12, 2015 18:03
|
|
|
hahhaha evol and I have gone round and round with selinux at least twice in the past year, I'm not going for a third, just check our respective post histories and pretend we argue about it for two pages. I was totally using yum more than 5 years ago, I ran rhel4 for the longest time. rhel4 was almost a decade ago, I ditched up2date for yum as soon as it was avail; I don't remember exactly when in the lifecycle but I was a pretty early adopter. We're getting old.
|
|
#
?
Mar 12, 2015 18:25
|
|
|
Just yesterday, setroubleshootd decided to take 100% of my CPU by dumping 8 billion lines into the logs about how some process was doing a thing that Wasn't OK, and how it stopped it from doing that, and you could totally run this grep command to change the behavior. SELinux is probably fine in static setups where you control the entire environment. For a user of a desktop system, it's the thing that randomly breaks your poo poo, the user model is "well, the user has to figure out arcane filesystem labels", and it's overall not a transparent system. Have you looked at the SELinux policy language? It's absolutely ridiculous. See how many dumb patches Fedora has to make to their own policy to get something usable: http://pkgs.fedoraproject.org/cgit/selinux-policy.git/ Questions that SELinux doesn't answer: why did the app try to do this? What danger is there if I allow the app to do this? How often has the app done this? How can I allow the app to do that or disallow the app from doing that easily? To me, user security is about transparency, auditing, and the ability for the user to set a policy and understand it. SELinux doesn't do any of those things. Anyway, I'm not overly mad about anything. Just playing my over-the-top sarcastic internet persona part.
|
|
#
?
Mar 12, 2015 18:38
|
|
|
Nooooo don't get evol started, just don't he's going to thesis you to death
|
|
#
?
Mar 12, 2015 18:42
|
|
|
Suspicious Dish posted:Just yesterday, setroubleshootd decided to take 100% of my CPU by dumping 8 billion lines into the logs about how some process was doing a thing that Wasn't OK, and how it stopped it from doing that, and you could totally run this grep command to change the behavior. For sure there are some serious flaws with SeLinux, and for a desktop OS I wouldn't recommend it. But for static environments as you mentioned it's not a bad thing at all.
|
|
#
?
Mar 12, 2015 18:55
|
|
|
calandryll posted:I just installed CentOS on a new home server, first time using CentOS as a primary server. What is the best way to work with the firewall? Some sites use iptables, others use firewalld and I'm sure others have mentioned other ways. I just want to add a few simple rules, ignore apache, subsonic, etc. It's mostly a matter of taste, but if you're just doing simple stuff I'd say use iptables and call it a day.
|
|
#
?
Mar 12, 2015 18:56
|
|
|
Powered Descent posted:It's mostly a matter of taste, but if you're just doing simple stuff I'd say use iptables and call it a day. You should use firewalld unless you plan on learning nftables syntax when iptables dies. Plus it's actually kind of human readable instead of needing to memorize various ports. Bhodi posted:I was totally using yum more than 5 years ago, I ran rhel4 for the longest time. rhel4 was almost a decade ago, I ditched up2date for yum as soon as it was avail; I don't remember exactly when in the lifecycle but I was a pretty early adopter. Bhodi posted:Nooooo don't get evol started, just don't he's going to thesis you to death But my general take is "run your server poo poo in permissive mode for a couple of days, generate a policy file from audit2allow, see whether you think it looks reasonable, and put it in enforcing". For desktops where users are constantly installing new software and doing a bunch of weird poo poo, it could be hard/bad. For relatively static servers? Almost no reason not to run it.
|
|
#
?
Mar 12, 2015 19:43
|
|
|
We ported yum to rhel3, rhel4 and ubuntu 5.10-7.04 so we could have consistency. RH may not have officially offered it at that time. It was in heavy use when I got there in oh, let's see, late 2006, early 2007, somewhere around there.
Bhodi fucked around with this message at 19:51 on Mar 12, 2015 |
|
#
?
Mar 12, 2015 19:47
|
|
|
all this systemd talk was quite interesting. Also it's funny that I started reading it right after trying to solve an old problem of the mpd not being able to start at boot for some reason, probably because it depends on some other service, but I can't find the solution on the webs. I think it needs to wait until the PC have an ip on my network, since I'm using the "bind_address 192.168.0.102" option since that's the only way for me to use mpd from my cellphone. I tried putting dhcpd on the "depend" block of the init script, both on "use" and the other option, to no avail. Do you guys have any idea?
|
|
#
?
Mar 12, 2015 21:44
|
|
|
program666 posted:all this systemd talk was quite interesting. Also it's funny that I started reading it right after trying to solve an old problem of the mpd not being able to start at boot for some reason, probably because it depends on some other service, but I can't find the solution on the webs. I think it needs to wait until the PC have an ip on my network, since I'm using the "bind_address 192.168.0.102" option since that's the only way for me to use mpd from my cellphone. I tried putting dhcpd on the "depend" block of the init script, both on "use" and the other option, to no avail. Do you guys have any idea? Debian? sysvinit? Depend on "networking", I think. dhcpd is definitely wrong and you're almost certainly not even running it. I think dhcpcd is triggered by network (maybe dhclient, it's been a long time), but "networking" is still the appropriate service, I think
|
|
#
?
Mar 12, 2015 23:37
|
|
|
Is there a way to make finch tile it's 'windows'? I'm getting tired of constantly having to alt+m / r things around. If not, is there another console-based solution like finch that supports tiling?
|
|
#
?
Mar 13, 2015 00:55
|
|
|
Is Ubuntu considered 'REAL' Linux to the geek crowd? I don't have my finger on the pulse of public opinion as much as I used to.
|
|
#
?
Mar 13, 2015 00:57
|
|
|
A3th3r posted:Is Ubuntu considered 'REAL' Linux to the geek crowd? I don't have my finger on the pulse of public opinion as much as I used to.
|
|
#
?
Mar 13, 2015 01:59
|
|
|
A3th3r posted:Is Ubuntu considered 'REAL' Linux to the geek crowd? I don't have my finger on the pulse of public opinion as much as I used to. Yes. Ubuntu is Linux. Canonical is a debatably lovely company with terrible engineering and open source practices from an "Linux" perspective, and the "geek" crowd is busy clapping each other on the back for successfully dragging themselves out of the last ditch archlinux put their system into to care about "noob" distros like Ubuntu. But if you wanna get poo poo done on a distro with a huge community and you don't care about standing on some kind of open source principles, need to run "enterprise" software, or care whether or not Canonical breaks kernel ABI in an LTS release, Ubuntu is capable, even great. E: yes, that's very backhanded praise. That's the best I can give them
|
|
#
?
Mar 13, 2015 03:52
|
|
|
evol262 posted:Debian? sysvinit? Depend on "networking", I think. dhcpd is definitely wrong and you're almost certainly not even running it. I think dhcpcd is triggered by network (maybe dhclient, it's been a long time), but "networking" is still the appropriate service, I think Thanks for answering my awfully described problem. It's sysvinit and gentoo. I'll try that.
|
|
#
?
Mar 13, 2015 04:29
|
|
|
The problem was actually that it was lacking the softlink net.eth0 to net.lo on init.d that gentoo uses as services for starting and stopping network interfaces (this is particular to gentoo as far as I know, and it's part of the installation but because of some stuff I didn't have it anymore), so I just created the softlink and re-installed mpd and it works.
|
|
#
?
Mar 13, 2015 05:01
|
|
|
I am using fedora 21 which happens to have selinux and i am not having issues with it so far, whenever selinux blocks something it usually tells me what and how to add a rule to allow it, it could be more user friendly though.
|
|
#
?
Mar 13, 2015 07:50
|
|
|
program666 posted:The problem was actually that it was lacking the softlink net.eth0 to net.lo on init.d that gentoo uses as services for starting and stopping network interfaces (this is particular to gentoo as far as I know, and it's part of the installation but because of some stuff I didn't have it anymore), so I just created the softlink and re-installed mpd and it works. mom, get the camera we've got an actual live gentoo user here
|
|
#
?
Mar 13, 2015 09:26
|
|
|
yeah lol, I really hope they never stop maintaining it since despite of all its problems I just can't adapt to the other distros anymore, unless there is another distro out there with USE flags and the same potential for customization that I don't know.
|
|
#
?
Mar 13, 2015 11:58
|
|
|
All the cool kidz are on arch now, the distro too cool for skool
|
|
#
?
Mar 13, 2015 12:51
|
|
|
Still on my (rolling release upgraded) 2009 installation  I've had to rescue it from no-boot conditions maybe 5 or 6 times
|
|
#
?
Mar 13, 2015 13:30
|
|
|
You mean arch? It's cool that there are other distros with rolling releases but that's far from the main feature on gentoo for me. My rolling release is from around 2009 too I think, I don't really know because this installation survived a complete change of hardware and I copied the files over to my SSD so the dates on the installation files (that I keep around to know when I installed my OS) have the dates of the copy. Funny thing, my processor changed from a very old AMD to a very new Intel processor and the whole system simply worked despite of the fact that every package supposedly being compiled with specific optimization for the AMD processor lol. E: but the windows installation had to be done from scratch
|
|
#
?
Mar 13, 2015 14:24
|
|
|
program666 posted:You mean arch? It's cool that there are other distros with rolling releases but that's far from the main feature on gentoo for me. My rolling release is from around 2009 too I think, I don't really know because this installation survived a complete change of hardware and I copied the files over to my SSD so the dates on the installation files (that I keep around to know when I installed my OS) have the dates of the copy. Intel and AMD have very few instructions which differ. You'd mostly find it being SIMD.
|
|
#
?
Mar 13, 2015 14:34
|
|
|
If there even was a single instruction it should at least get a bit buggy didn't it? I mean, I just copied the files over, not a single hitch. I imagine gentoo optimizations are mostly useless right?
|
|
#
?
Mar 13, 2015 14:47
|
|
|
program666 posted:If there even was a single instruction it should at least get a bit buggy didn't it? I mean, I just copied the files over, not a single hitch. I imagine gentoo optimizations are mostly useless right? Did you configure your kernel to support only AMD procs, or leave in the intel stuff? Thats the only time I can see it causing real problems that you would be able to see.
|
|
#
?
Mar 13, 2015 15:16
|
|
|
You have separated installation packages for the initial files that are supposedly compiled with optimizations for one or another processor, also you use a compilation parameter that supposedly compile every package on your system with those kind of optimizations also. I thought that meant introducing the more efficients assembly instructions that one processor had but the other didn't in every binary where useful. Maybe it does but it's never useful  .
|
|
#
?
Mar 13, 2015 15:27
|
|
|
|
| # ? May 31, 2024 20:11 |
|
|
program666 posted:You have separated installation packages for the initial files that are supposedly compiled with optimizations for one or another processor, also you use a compilation parameter that supposedly compile every package on your system with those kind of optimizations also. I thought that meant introducing the more efficients assembly instructions that one processor had but the other didn't in every binary where useful. Maybe it does but it's never useful They're not "gentoo" optimizations. They're GCC, and you can read about them here. As a general rule, intel and amd are binary compatible anyway. I think 3dnow may be the only instruction set that Intel doesn't implement that AMD does, but that's a separate USE flag that hardly any packages implement and you probably didn't have turned on anyway. But when we say something is "binary compatible", that's what we mean anyway. The instruction set is the same. I don't know whether you used march or mtune, but it doesn't matter. Your binaries probably wouldn't have worked on an older CPU missing at least one of the newer instruction sets, but they go forward. You may be dramatically overestimating how much optimization the compiler does for you just by setting a single flag. It basically says "we know that for these given mathematical operations, using this instruction is faster, and you said we should built with support for that instruction (mtune) or explicitly exercise that instruction (march)". That's it. And your application may not even support it. Anything else, like cache sizing or whatever is up to you by deciding whether or not you want to unroll loops. USE flags aren't magic either. It has no way of looking at the code and figuring out whether a given SIMD set would be helpful and whether you have it (and again, SIMD is basically the only place Intel and AMD differ outside of virt extensions, and that difference disappears once a year when the other company implements the new instructions and catches up). USE=someflag says "try this application with ../configure --with-someflag", if it supports it. That's all. If the developers didn't add --with-something (which is almost certainly going to activate a code path with templates or macros or whatever equivalent exists in that language), it does nothing. In ye olden days (pre-pentium), there were big differences. Arch's big pull back in 2002 or whatever is that it was "compiled for i586". Now there aren't. Now everything is an extension or cpuflag. Your system is probably far less optimized than you think, and it's definitely far less specific to your system than you think.
|
|
#
?
Mar 13, 2015 16:16
|
|