Re: U.S. Court PACER system overloaded by public interest
Anyone that regularly uses PACER should absolutely be using https://www.courtlistener.com/. On Fri, Aug 26, 2022 at 1:07 PM Sean Donelan wrote: > > > Having some experience with documents of extreme public interest, and web > sites getting overloaded (Starr Report on President Clinton, 1998)... > > its nice to see government web sites still get overloaded several decades > later. > > "PACER Service Under Fire After Trump Affidavit Crash Reports" > > PACER is the electronic document system used by the U.S. Court System. > -- Jeff Ollie The majestik møøse is one of the mäni interesting furry animals in Sweden.
Re: Linux: concerns over systemd [OT]
On Mon, Oct 27, 2014 at 10:35 AM, Jay Ashworth j...@baylink.com wrote: I will stipulate this use case. I will counter with you wouldn't be running a real distro in that case anyway; you'd be running something super trimmed down, and possibly custom built, or based on something like CoreOS, that only does one job. Well. :-) From: https://coreos.com/using-coreos/systemd/ CoreOS uses systemd as the core of its distributed init system, fleet. Systemd is well supported in many Linux distros, making it familiar to most engineers. Every aspect of CoreOS is deeply integrated with systemd. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Fri, Oct 24, 2014 at 10:10 AM, Jim Mercer j...@reptiles.org wrote: On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote: All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. in FreeBSD, the bulk of the rc.d scripts are basically the same format, inhaling a standardized library of functions, populating some variables, maybe adding a few custom functions, then jumping to main. If all of the scripts are cut'n'paste copes of each other, wouldn't it be better to figure out a way to stop cutting and pasting? I can't count the number of times I've run into problems with my code because of that, never mind how many times it's happened in other people's code. -- Jeff Ollie
Re: Linux: concerns over systemd [OT]
On Thu, Oct 23, 2014 at 12:28 AM, George Herbert george.herb...@gmail.com wrote: Ok. As a highly on- list-topic example of why distrust is called for... Without referring to the systemd source code*, does anyone know what systemd uses to select between networking subsystems (i.e. NetworkManager, the new standard as of RHEL 7, vs /etc/ sysconfig/network-scripts/, etc.). NetworkManager is default but disableable and it magically falls back to network-scripts dir, but the fallback is nearly undocumented and the selection behavior appears completely undocumented. systemctl status NetworkManager.service systemctl status network.service I don't think that there's anything magic about it, you have one or the other enabled. Adding NM_CONTROLLED=yes/no to /etc/sysconfig/network-scripts/ifcfg-* gives you per-interface control over whether NetworkManager or the network scripts are used for managing the interface. If neither is enabled you probably end up with no networking. If by some chance you do know this, where did you come by that knowledge? Hopefully with URLs. I have access to systems that run systemd and I tried a couple of things... Also, I've been managing Red Hat systems for a long time and have known about this for a while. But a little bit of googling and I found this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-NetworkManager_and_the_Network_Scripts.html Unless you're running systemd-networkd, this is really distro-specific stuff as I expect that most distros will want to preserve some backward compatibility with legacy network configuration. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo israel.l...@lugosys.com wrote: Not intending to start a flame war here. Bull. If you've been around the FOSS community even for a short while, you'd know that systemd has become a religious topic akin to Emacs vs. Vi discussions etc. I realize that many of the people that read the NANOG list also use Linux systems, but that's not what I come here for. Please, take the systemd discussions to the mailing lists for your distribution of choice. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 11:12 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Seems to me, this has been a very rational discussion, Hardly. The discussion so far has been weighted very heavily on the side of Dana Carvey's Grumpy Old Man-style whining. That's the way it was and we liked it!. The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. There's no way to argue rationally with that. confined to one very identifiable thread, Thank goodness! containing what at least this reader finds very useful (operational impacts of systemd in server-side environments, and what alternatives people are looking at). Just because it's useful, doesn't mean that it isn't off-topic for NANOG. At least until Cisco starts using systemd as pid 1 in IOS XE I suppose... If you're not interested, you have a delete key. Please use it, and don't turn this into a flame war. Sure, I have a delete key, but it'd still be better if people moved this discussion somewhere more appropriate. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 11:43 AM, C. Jon Larsen jlar...@richweb.com wrote: Hardly. The discussion so far has been weighted very heavily on the side of Dana Carvey's Grumpy Old Man-style whining. That's the way it was and we liked it!. The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. There's no way to argue rationally with that. Incorrect assumption. systemd is a massive security hole waiting to happen The same can be said for any software. Shellshock anyone? How many security issues remain in bash? One of the reasons systemd was first written was to get rid of the the tangle of shell scripts that are used to start up a system using sysvinit. and it does not follow the unix philosophy of done 1 thing and do it well/correct. Its basically ignoring 40 years of best practices. Thats why folks that have been there, done that, dont want any part of it. Not because its new, but because its a flawed concept. I was going to write a longer response here, but this: http://lwn.net/Articles/576078/ sums up my thoughts on the unix philosophy. It's not the be-all-end-all that you make it out to be. Again, this sounds a lot like Grumpy Old Man complaining. You are free to use it, but it would be a poor choice for system that has hopes of being secure. I would disagree, especially since systemd makes it practical to use many of the capabilities of the Linux kernel that can improve security, like filesystem namespaces, cgroups, etc. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 12:35 PM, George Herbert george.herb...@gmail.com wrote: On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie j...@ocjtech.us wrote: The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. There's no way to argue rationally with that. I think you are monumentally misreading the situation. A) Change is the constant in IT. Staying relevant and employable has put me through five or more generational shifts in enterprise OS, plus diversions to Mach, Plan 9, MacOS, etc. Change is normal. I agree with you about change, but there are a number of people that vocally resist any kind of change, no matter what. There's little that can change their mind other than time. It's a useful skill to be able to recognize these people and not to let them get you down. B) Systemd and the Solaris SMF that it conceptually followed have a number of technical flaws, ranging from obscure interfaces (sometimes requiring source code to understand) to lack of human readable configs to (at least with SMF, and as far as I can tell systemd) a lack of ability to even print/dump out the current dependencies and ordering tree. I have no experience with Solaris SMF so I can't comment on it specifically, but in my opinion systemd: 1) has excellent documentation, especially when you compare it to other open source documentation. 2) What's more readable than .ini files? They even avoided the temptation to use XML. I can't tell you how much time I've wasted reading shell script spaghetti trying to figure out exactly how a service is started up. Services implemented in Java and Ruby seem to be especially bad at that. 3) systemctl list-dependencies, although since service start-up in systemd is highly dynamic it's difficult to predict what order services will start up. C) In both systemd and SMF a tremendous unpreparedness of training and documentation accompanied rollout. These were not reasonably enterprise ready at launch, or now. In 2010/2011 when systemd was first being integrated into Fedora (and I believe SuSE) I would have agreed with you. However this is four years later and I couldn't disagree with you more. More to the point, Red Hat disagrees with you, given that they have put their money where their mouth is and integrated systemd into RHEL7. D) The architectural case that the services adopted in systemd over time belong there or are safe there is not proven, and not that I see well argued or documented. Conglomerated services are at least to be eyed skeptically. I did not closely follow systemd's development but it is evident from a distance that operator feedback in the community and to Sun regarding SMF flaws was somehow missed in systemd's development as they did the same wrong things. A change this big deserves architectural clarity and justification. I don't follow systemd development closely either, but Lennart Poettering, Kay Sievers, et. al. have made extraordinary attempts to communicating about systemd. They've appeared at numerous conferences and given talks about systemd, written blog posts, documentation, etc. I don't know what else they can do other than to be invited over to everyone's home for tea and a systemd discussion. We get snide comments about change being good and core developers Linus evidently feels are unsafe. We also get snide comments about change being bad. As for Linus, other than the fact that he has an extraordinary amount of influence over what goes into the kernel, I've learned to take his comments on other matters with a very large grain of salt. I have a lot of respect for the guy, but his attitude and behavior towards other people is appalling. What's really surprising about some of Linus' comments WRT to systemd is that one of systemd's main goals is to make it easier to use some of the advanced functionality of the Linux kernel that were little used or ignored before. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 2:13 PM, John Schiel jsch...@flowtools.net wrote: On 10/22/2014 10:43 AM, C. Jon Larsen wrote: Incorrect assumption. systemd is a massive security hole waiting to happen and it does not follow the unix philosophy of done 1 thing and do it well/correct. i was beginning to wonder how secure systemd is also. Personally, I feel that the systemd developers have given a lot of thought to security, both in the systemd code itself and because systemd makes it practical to use advanced features of the Linux kernel that can improve security. One example is the fact that systemd makes it very easy to give a service a private /tmp and /var/tmp directory that no other service uses by using Linux's filesystem namespaces. That can avoid all sorts of tmpfile race conditions that have caused problems in the past. Doing that in sysvinit, while possible, wasn't easy because you'd have to modify each init.d script (and redo the change every time upstream released a new update) to create/manage the filesystem namespace. In practice it was never done. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 2:30 PM, valdis.kletni...@vt.edu wrote: On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: i was beginning to wonder how secure systemd is also. One of the 3 CIA pillars of security is availability. And if it's oh-dark-30, figuring out what symlink is supposed to be where for a given failed systemd unit can be a tad challenging. At least under sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). How long has it been since you've looked at/used systemd? Manual management of symlinks to control what services are started at boot time are a thing of the past. systemctl enable|disable|status service will handle all of that for you. I agree, managing symlinks was annoying in the early systemd days, but I haven't messed with those symlinks manually in a long time, except to remove orphan symlinks caused by services that weren't removed cleanly from the system. I think your fear comes more from a lack of familiarity with systemd, rather than a true technical deficit. Personally I find systemd services much easier to debug, especially since stderr and stdout from all services is captured, rather than being lost to /dev/null. I find it VERY annoying that many init.d scripts eventually boil down to /usr/sbin/program --someflags 21 /dev/null . And if they carry through on their systemd-console threat, that could get even worse - that introduces a whole new pile of risks for being unable to diagnose early boot bugs I haven't seen much about systemd-console, but I thought that this reddit thread was interesting. http://www.reddit.com/r/linux/comments/1rmj9e/systemd_is_about_to_gain_a_system_console_boot/ It seems to me that moving VTs out of the kernel and into a userspace process would be a good thing. I guess one could argue about whether systemd is the right place for it, but as you can see from that reddit thread there have been a number of other projects that have attempted to do that but have failed to gain traction for one reason or another. One thing that the systemd developers are undeniably good at is getting their work adopted by the distributions. So yeah, there's security issues other than can it be hacked because it's got a huge surface area. Nothing new here. And before you get started, Bash and OpenSSL prove that old code isn't necessarily secure code. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 3:22 PM, John Schiel jsch...@flowtools.net wrote: On 10/22/2014 01:30 PM, valdis.kletni...@vt.edu wrote: On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: i was beginning to wonder how secure systemd is also. One of the 3 CIA pillars of security is availability. And if it's oh-dark-30, figuring out what symlink is supposed to be where for a given failed systemd unit can be a tad challenging. At least under sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). Agreed, the oh-dark-thirty call outs will be harder to resolve but I'm sure some folks will learn to deal with it. It's new and changes the job but as was noted earlier, there is always change. I disagree. I believe that the features of systemd will make oh-dark-thirty call outs easier to resolve, but only if you take the time to familiarize yourself with the tools at hand *before* problems happen. But really, there's nothing new here. *Of course* systems that are unfamiliar to you will be more difficult to fix. It'd take *me* *forever* to fix a problem on the HP-UX systems at work, mainly because I'd spend too much time figuring out where everything was. However the guy in the cube next to me wouldn't have that problem... To borrow Barry's automotive metaphor, this is like saying that electric motors are bad because I only know how to fix gasoline engines. -- Jeff Ollie
Re: Linux: concerns over systemd [OT]
On Wed, Oct 22, 2014 at 3:34 PM, Randy Bush ra...@psg.com wrote: the vast majority of negative tongue wagging regarding systemd is ill informed. can we skip the ad homina and leave that for the systemd dev fora? I don't think that it's an ad homina attack, as it's pretty clear that many of the people commenting have not spent a significant time using systemd so many of their comments are based on what they've read on the Internet, not from practical experience with systemd. does systemd have growing pains? definitely. are some egos involved? sure. can systemd be far reaching? yes, is such reach mandated? no. use the units you want and disregard the rest. how does this work out in practice? at install, can i choose whether systemd is used for X as opposed for the separate component? can i template such choices for cluster deployment with the usual tools? I think that Debian's plan to allow multiple init systems (irregardless of which one is default) is a bad plan. The non-default ones won't get any love - at some point they'll just stop working (or indeed, work at all). Allowing choice of components is a good thing at one level (e.g. sendmail vs. postfix vs. exim). I really don't care (and don't really even remeber) which SMTP server is installed by default on my systems because my configuration management system makes sure that the SMTP server that I prefer is installed and configured the way I want it once the system is up and running. For something like PID 1, each distribution should make a choice and stick with it. I really couldn't care what Debian's init system is, as I don't use Debian (never have, at least not when I have had a choice). If Debian goes through with the switch to systemd, they won't gain me as a user as there are a host of other reasons that I prefer something other than Debian (or Debian-derived) distributions. If a group of people fork Debian because of systemd, more power to them. -- Jeff Ollie
Re: Linux: concerns over systemd [OT]
On Wed, Oct 22, 2014 at 3:48 PM, valdis.kletni...@vt.edu wrote: On Wed, 22 Oct 2014 19:35:51 -, David Ford said: into a common bus. not everything in systemd is a requirement to run it. just because a unit is offered for dhcp or ntp, doesn't mean you are required to use it. Actually, systemd 216 will cram systemd-timesyncd down your throat even if you had ntpd installed. Oh really? From my Fedora 21 (alpha) system at work: # rpm -q systemd systemd-216-5.fc21.x86_64 # systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled) Active: inactive (dead) Docs: man:systemd-timesyncd.service(8) # systemctl status ntpd.service ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: active (running) since Thu 2014-10-16 16:06:22 CDT; 6 days ago Main PID: 1438 (ntpd) CGroup: /system.slice/ntpd.service └─1438 /usr/sbin/ntpd -u ntp:ntp -g I'm not sure what NTP service is installed by default in Fedora 21+ (which will ship with systemd 216), as this system has been upgraded from previous Fedora versions, but as you can see it's perfectly possible to run ntpd on a system that used systemd 216. https://bugzilla.redhat.com/show_bug.cgi?id=1136905 https://mail.gnome.org/archives/distributor-list/2014-September/msg2.html Lennart's attitude was pretty much why would anybody want to run ntpd when they have our SNTP implementation: A vast oversimplification of Lennart's point. Basically you left off if you really want to run chronyd or ntpd service go right ahead, we're just not going to have code in systemd to do that for you. http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html There's been similar issues with their dhcp. The bug here is really timedatectl (a component of systemd) isn't going to manage chronyd or ntpd (third party packages), and that made a Gnome control panel (which used timedatectl under the hood) report that network time synchronization wasn't enabled. If you don't want timedated then it's perfectly possible to disable timedated and use something else. If someone cares enough, I'm sure that the Gnome control panel will get updated so that I can manage chronyd or ntpd itself. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: 1. Experimentation and learning curve take time. That's a real cost that's being imposed. What makes systemd different from any other technology in that respect? It's not clear that the benefits outweigh the costs of the status quo. Ultimately this is a very personal decision, but given the adoption rate of systemd by distributions I don't think that it's going to be that long before people (at least if you want to be employed managing Linux systems) don't have a choice but to become at least passably familiar with systemd. Even if Debian steps back from systemd, Canonical and Red Hat have committed to systemd. 2. Assumes good documentation. Not a given with systemd, as it stands now. Why does everyone assume that systemd doesn't have good documentation? I personally have found the documentation to be excellent. 3. Assumes that problems are easy to track down. Harder to do with murky and monolithic code. Statements that are equally valid for sysvinit. (I still shudder the first time udev did something completely counter-intuitive at 0-dark-30, and that's from the same cast of characters. Udev predates systemd, by a long long time. If you have problems with udev don't blame systemd. 4. More fundamentally, 0-dark-30 events are almost always unexpected (other than in the sense of Murphy's Law), and tricky to resolve - one has hopefully prepared for the expected. Hence, it's not completely clear that one CAN familiarize oneself in a meaningful way - particularly when talking about something as monolithic as systemd. That's one of the major reasons for keeping things modular, and keeping modules simple. This really has nothing to do with systemd. I believe that systemd has made things better in this respect, but you're welcome to believe that the pile of shell scripts in /etc/init.d is better. sarcasmI mean really, what could go wrong when we configure boot-up with a Turing complete language?/sarcasm Really... I know of several instances a poorly-written init script caused boot-up to fail because they had infinite loops in them. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 4:43 PM, Rich Kulawiec r...@gsp.org wrote: On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote: The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. That's an entirely unfair characterization. Some of us, including a lot of people on this list, have been pushing the envelope on change for decades. We've run alpha software on beta hardware, cobbled together networks with duct tape, and burned a lot of midnight oil while making innumerable mistakes and learning from them. Speaking for myself, after migrating through far too many Unix and Linux distributions to count, starting with Research Unix v6, my entire professional career has been *constant* change. I suspect that the same is true of everyone else who's been doing this for a while. Anyone who doesn't embrace change as a way of life probably isn't on this list; they're somewhere else, maintaining Cobol written during the Nixon administration. Been there, done that, got the T-shirt. My problem with systemd is not that it's a change: it's just one more out of tens of thousands and so, in that sense, it's really not a big deal. My problem with it is that I think it's a bad change, one not in keeping with the software tools philosophy that has served us ridiculously well for a very long time and -- so far -- has not been shown itself to be in need of replacement. A Leatherman pocket multitool is highly useful: I've had one for years. It's great. Until you need two screwdrivers at the same time...at which point it becomes obvious why serious mechanics/craftsmen carry around a toolbox with dozens of tools and why glomming all of those into one supertool would be A Very Bad Move. I carry a Leatherman too, and indeed it is a very useful tool. But it's useful in the real world because physical tools have mass, and there's only so much mass that a person wants to carry around with them all of the time. In all other respects the tools on a Leatherman are far less superior than a tool purposely designed for a task. Software doesn't have mass so your analogy doesn't quite work. systemd is a tool designed to get the system to a state where real work can be done. NTP servers, DHCP clients, consoles, aren't the real work of a system, or at least I hope not, because that would be boring to me. I'm not going to justify everything that the systemd developers have done here, but I've been convinced that the functions that they have moved into systemd have been justified because it'll make systems work better and more robustly. Similarly, the monolithic (and ever-expanding) nature of systemd is a strategic design error. That's probably not obvious to people who measure their experience in years instead of decades -- it wouldn't have been obvious to me back in the day either. But it's pretty clear from here, and dismissing it as hey you kids get off my lawn geezer whining is not going to advance the discussion. You may have been in the biz longer than I have, but not by as much as you think. I didn't immediately see the value of systemd, but it didn't take me long. Your arguments still come off as appeal to tradition. It was impolite to call it old geezer whining was impolite but that doesn't change the nature of your argument. It would be better, I think, to pull out a copy of Kernighan and Plauger's book -- which is rather brief, actually -- read it cover-to-cover, and then consider carefully whether the myriad-and-steadily-increasing number of functions being subsumed by systemd should actually be in one program. It's been a while since I've read it, but ISTR that the modularity that KP speak of refers to procedures and functions, they didn't seem especially afraid of big programs. And from what I've seen the systemd code is properly modularized in the sense that KP use. Speaking of which, did you know that sysvinit has no unit tests (or tests of any other kind)? And since every init script is code (even though many people treat it like configuration data) why don't they have unit tests either? systemd has an extensive test suite, that gives me some reassurance that bugs, once found, won't be reintroduced. And I'm sure that if we went through the Elements of Programming Style point by point there is much more in systemd's favor. If that doesn't suffice, then I suspect it will only require waiting a little while until a demonstration of why monolithic integration is a bad idea will be provided by someone who is at this moment studying the large-and-growing attack surface presented by systemd. I hope I'm wrong about that. I'm probably not. Software is software. I'm sure that bugs (including security bugs) will be found. Film at 11. Nothing new here. -- Jeff Ollie
Re: Linux: concerns over systemd [OT]
On Wed, Oct 22, 2014 at 4:48 PM, na...@jack.fr.eu.org wrote: Bah, boot speed; On my server, boot is slow down by hardware initialization. The soft side is quite low. But the point is not makes things faster from 15 to 14 sec is useless. The point is : it's good, but at what price ? I agree that boot speed is a red herring. Booting in a highly dynamic environment is really one of systemd's key achievements. True, this is most apparent in systems like laptops that can be docked/undocked, tend to have a lot of USB devices added/removed, etc. But servers have these same issues, if only in lesser degree. sysvinit generally had to wait for a fixed interval for all hardware to finish initializing. It was a little more sophisticated than one init script having a sleep X command in it, but not much. systemd is able to start services as soon as all of the hardware it needs is ready, rather than waiting arbitrary amounts of time and then possibly failing anyway because it didn't wait long enough. One main example of this is a large RAID array or LVM volume that's used for data storage (not the OS). systemd can let parts of the system boot that don't require the data storage to be present start up while waiting for all of the data storage drives to spin up and get assembled. As you said, there were many improvements over the past. What was the clean bit cost ? None but benefits, right ? What about fs logs ? Does it have a cost ? If systemd is just about time, it will be fine. But why trying to recreate (ans thus, squeeze) some old daemons like cron or syslog ? Both of them are doing a perfect job. Syslog didn't capture the stdout/stderr from daemon start up. Syslog did only a mediocre job of capturing dmesg from early boot. If you have access to a system running systemd/journald run journalctl -k -b. That'll show you all of the kernel messages since the last boot. At least on the RHEL systems that I have access to, /var/log/dmesg doesn't timestamp the lines in the file, making it difficult to impossible to correlate with other log lines. The kernel messages in /var/log/messages are timestamped with the time that rsyslog was able to (finally) start and pull the messages out of the kernel message buffer. Can I use systemd without any of journald stuff ? I wouldn't want to. If not, then the 1sec speedup is far too expensive. The boot speed up is a nice benefit, but not the only (or even the best) reason to use systemd. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 7:36 PM, Israel G. Lugo israel.l...@lugosys.com wrote: For example, I'm very interested in NTP and accurate timekeeping -- mostly as a personal hobby, but it's been useful at work as well. I for one would definitely not consider NTP one of those details that just come with the bootup process. As you can see in another email I posted, it's trivially easy to disable systemd's NTP implementation and replace it with another. The same goes for systemd's DHCP server, as far as I know there's no distribution using it by default yet. Fedora is still using NetworkManager, I think that RHEL 7 defaults to the same network scripts that have always been used, although it's very easy to switch to NetworkManager if that's what you want. So a lot of the whining you see about systemd forcing a NTP or DHCP server on you is hyperbole by people that have read a few articles on slashdot/reddit/whatever and take that as gospel. I did find it interesting, however, what you mentioned in another email, about systemd implementing certain isolation features such as separate filesystem namespaces and so on. That may be very useful. Yes, indeed, very useful. I think the main point that we could hopefully all agree on here, is that it would be very difficult to have a single one size fits all solution. The requirements and concerns of the desktop, for example, are simply too different from those of the server or router space. I have found the desktop vs. server arguments with respect to systemd unconvincing. I find many/most of the features of systemd useful in both contexts. I think that the problem with the desktop/server dichotomy is that servers are no longer what they used to be. Servers used to be these things that sat in the back room and would reboot once or twice a year when a kernel upgrade needed to be applied. With the advent of the cloud and related technologies servers have become much more dynamic and then the advantages of systemd become much more obvious. systemd, for better or for worse, can't be the one magic bullet. Great or terrible as though it may be, I don't much like the total break in compatibility (correct me if I'm wrong). total break in compatibility is a bit much, as the systemd developers went to great lengths to make sure that init scripts continue to work pretty much as you would hope them to under systemd. I'm not saying SysV is all that good, but there are other replacements, and new ones can be designed, but don't make it so that everyone-has-to-use-yours-or-else! No one forced Debian to adopt systemd except Debian. If Debian does go through with the switch no one is forcing you to stick with Debian. I guess we have GNOME to thank for that... Well, I guess the Gnome developers saw some value in systemd integration that others don't. There are other desktop environments out there. And that's what troubles me the most: the lack of choice that seems to be creeping up, with everyone just ganging up and jumping to systemd like the floor is on fire. I'm with Jay Ashworth on this one: what gives?? Somehow I doubt that Lennart Poettering has the hypnotoad (ALL HAIL THE HYPNOTOAD!) in his pocket. I don't think that Lennart Poettering is a billionaire and can afford to bribe everyone in charge of all of the distributions (and I'm sure that most of them wouldn't take one anyway). Why do people keep assuming some sort of evil conspiracy on the part of the systemd developers and refuse to believe that systemd is becoming the default because the right people in the right places have been convinced of systemd's technical benefits over sysvinit? The reason that there's lack of choice is because the people that don't want systemd haven't stepped up to do the work and create their own distribution. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Re. NTP: Timekeeping is rather essential in lots of applications - like, for example, transit operations, where I currently spend my work life. An accurate, accessible central clock tends to be a rather important system component. And we're talking concerns in the range of seconds. When you start getting into serious real-time systems (laboratory instrumentation, utility operations, warfighting, ) - yeah, NTP servers start getting really interesting, to a lot of people. As I've already said a couple of times, systemd does not force a particular NTP implementation on you. It comes with one (timedated), and has a utility to manage it (timedatectl) but the admin can install and use a different one if they like. The only thing that has changed recently with respect to that is that timedatectl can no longer be used to manage chronyd or ntpd. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 9:08 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Hey... how about not using selective editing to change the thread of discussion (see below) If you're going to simply keep repeating I like systemd, everything is copacetic - maybe you should take your fanboy attitude elsewhere, and let those of us concerned with operational impacts have a meaningful conversation here. Sigh, this is *exactly* why I should have stayed out of this. I hadn't seen much in terms of meaningful conversation before I posted, just a lot of hand-wringing about the doom about to happen. The arguments against systemd that I've seen so far: 1) It's different so it's bad. 2) There's a lot of code, there must be some really bad security problems just waiting to happen, so it's bad. 3) It doesn't do things the way we've always done them, so it's bad. 4) The systemd developers are jerks, so it's bad. And maybe, you should check out some of the upstream bug reports re. systemd interactions with NTP. While I don't have infinite amounts of time to read every mailing list thread or bug report, I have seen quite a few of them. And I think that a lot of the time, people are forgetting that it's difficult in email/textual communication to convey emotional subtlety and that can easily cause problems. Plonk. Have fun in your nice quiet world where no one disagrees with you. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On Wed, Oct 22, 2014 at 9:18 PM, valdis.kletni...@vt.edu wrote: On Wed, 22 Oct 2014 20:45:01 -0500, Jeffrey Ollie said: As I've already said a couple of times, systemd does not force a particular NTP implementation on you. It comes with one (timedated), and has a utility to manage it (timedatectl) but the admin can install and use a different one if they like. Yeah, and if you want anything else to integrate in with systemd other than the supplied SNTP, you can pretty much go pound sand, according to Marcel Holtmann: So this means that you get a really good basis where clocks are synchronized. If you want something better, you can install it. It is a waste of time trying to integrate anything else than timesyncd since if you use anything else, you will manually configure it and use its advanced options. If you do not need the advanced features, then why install other NTP clients in the first place. http://lists.freedesktop.org/archives/systemd-devel/2014-August/022572.html You should read the whole thread at freedesktop - it's pretty obvious that there's a really heavy bias towards we have a solution that's good for desktops, and if you have a different use case, go pound sand. Yes, I've read the thread, and I think go pound sand is an unfair characterization of what *I* saw in that thread. To achieve the level of integration that timedated has with the rest of systemd would require more than just putting code into timedatectl to write out /etc/ntpd.conf and starting a service. timedated talks to networkd (that DHCP server that everyone is hating on as well) in real-time to determine the state of the network and to get any NTP servers that were sent in DHCP packets. To do that for chronyd or ntpd in the same way would require code changes and the systemd developers didn't want to do the work, as far as I know no one else has done the work, and I'm skeptical of the chances that such patches would get accepted upstream. So, if you want/need to run chronyd or ntpd you can, it'll integrate into the system just like any other service would, and you'll be no better/worse off than before timedated came into existence. -- Jeff Ollie
Re: Linux: concerns over systemd [OT]
On Wed, Oct 22, 2014 at 9:48 PM, Jimmy Hess mysi...@gmail.com wrote: On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein b...@world.std.com wrote: And you whisk all that away with it's not really clear to me that 'reboots in seconds' is a think to be optimized False dilemma. [ snip ] 10 seconds from power on to user interface for desktops, will meaningfully improve the user experience, but not for servers. It's a false dilemma only if you're thinking about traditional physical servers. Consider: 1) What if you're spinning up several thousand Hadoop nodes on AWS or GCE so that you can do some sort of big data operation. 2) What if PewDiePie just mentioned one of your products in a video and you need to quickly scale up the number of backend servers to handle the load. I'm sure that there are many other scenarios that I could devise where a fast server boot time was important. -- Jeff Ollie
Network diagnostics for the end user
Are there any tools out there that we could give to our end users to help diagnose network problems? We get a lot of the Internet is slow support calls and it would be helpful if we had something that would run on the end user's computer and help characterize the problem. We have central monitoring system of course but that doesn't always give a complete picture, as the problem could always be on the end user's computer - slow hard drive, not enough memory, wrong name servers, etc.
Re: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.]
On Sat, Dec 1, 2012 at 4:21 AM, Patrick W. Gilmore patr...@ianai.net wrote: It amazes me how people feel free to opine on things... Actually, what really bugs/amazes me about that thread is that the person whom this thread was originally about IS NOT EVEN FROM THE UNITED STATES OF AMERICA. CALEA, DMCA, yadda, yadda, yadda have nothing at all to do with the original problem. -- Jeff Ollie
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth j...@baylink.com wrote: The real question is whether it was issued after HHGTTG. HHGTTG first appeared on the BBC in 1978. Thinking Machines Corporation was formed in 1982. As far as I can tell the first BGP RFC is 1105 and was published in 1989. -- Jeff Ollie
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 3:11 PM, Robert E. Seastrom r...@seastrom.com wrote: Jeffrey Ollie j...@ocjtech.us writes: On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth j...@baylink.com wrote: The real question is whether it was issued after HHGTTG. HHGTTG first appeared on the BBC in 1978. Thinking Machines Corporation was formed in 1982. As far as I can tell the first BGP RFC is 1105 and was published in 1989. http://tools.ietf.org/html/rfc827 Which describes EGP and was published in 1982. EGP does use the notion of an autonomous system number. When the conversion from EGP to BGP was made did networks keep the same autonomous system numbers? -- Jeff Ollie
Re: Root Zone DNSSEC Deployment Technical Status Update
On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli joe...@bogus.com wrote: On 7/16/10 11:07 AM, Tony Finch wrote: On Fri, 16 Jul 2010, Chris Adams wrote: A simple XSLT will transform it into any needed format. XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. anchors2keys will. Actually, it won't. The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does. -- Jeff Ollie
watchmy.net?
Can anyone log into watchmy.net and manage their account? Our network has changed so I need to get in and change my settings so that I stop getting bogus alerts. Unfortunately there seem to be some PHP coding errors so I can't log into the site. I've mailed b...@watchmy.net (once on 1/14 and once on 3/25) but I've received no response, so I'm reduced to bothering everyone here. -- Jeff Ollie
Re: news from Google
On Fri, Dec 4, 2009 at 5:29 AM, Jorge Amodio jmamo...@gmail.com wrote: I'm more concerned about information that by law is being made public and available on-line (like property records in the US) out of my control, or not very easy to opt-out. Property records have always been public information in the US, and no one can opt out (well, I suppose you could sell your house). Having information like this available to the public is important because the government uses those records to make decisions like property tax rates. If you were allowed to opt out it would be difficult or impossible for the public to monitor these government actions. For example, if you thought that you were being charged more property tax than you thought you should you could examine the property records for properties that were comparable to yours and see what they were being charged. If all of your neighbors had opted out you wouldn't be able to do that (at least not with out going to court). Similarly, if you were looking at buying a house you could check the property records to see if any liens had been made against the property or if you could afford to pay the property taxes. -- Jeff Ollie
Re: options for full routing table in 1 year?
On Wed, Apr 8, 2009 at 8:33 PM, Jo Rhett jrh...@netconsonance.com wrote: I was chatting with someone the other day and we were trying to build a complete list of all units which can handle full routing tables 1 year from now, assuming current 4k/month growth (nevermind de-aggregation) What about Cisco's ASR series? We're going to be turning up a multihomed connection with two full BGP views and I think our reseller is going to be recommending ASR series routers... -- Jeff Ollie
Re: Fiber cut in SF area
On Thu, Apr 9, 2009 at 2:44 PM, Michael Holstein michael.holst...@csuohio.edu wrote: First one is in this proximity : 37°15'20.79N 121°48'9.38W Street view shows a few manholes in the vicinity. Second one is in this proximity : 37°29'44.00N 122°14'44.31W Didn't see anything obvious here. -- Jeff Ollie
Re: ISC DLV
On Sat, Apr 4, 2009 at 11:55 PM, Marcelo Gardini do Amaral mgard...@gmail.com wrote: are you having problems to validate DNSEC using ISC DLV? Yes, I had to disable DNSSEC validation a few hours ago to get DNS resolution operating again. -- Jeff Ollie
Re: Private use of non-RFC1918 IP space
On Mon, Feb 2, 2009 at 9:48 AM, Trey Darley t...@kingfisherops.com wrote: Some colleagues and I are running into a bit of a problem. We've been using RFC 1918 Class A space but due to the way subnets have been allocated we are pondering the use of public IP space. As the network in question is strictly closed I don't anticipate any problems with this as the addresses would be unambiguous within our environment. I'm curious if anyone else is doing this. I'd recommend against it, because even though the network is not connected to the Internet now you never know what the future holds. Even if it's never connected there are always things that seem to pop up and cause problems. Also, if you're address allocation policy has been so badly managed that you've run out of space in 10.0.0.0/8 adding more IPs to the pool isn't going to help for very long. -- Jeff Ollie You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe. -- Marcus to Franklin in Babylon 5: A Late Delivery from Avalon
Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)
On Thu, Jul 24, 2008 at 3:05 AM, Steven M. Bellovin [EMAIL PROTECTED] wrote: The round trip issue affects latency, which in turn affects perceived responsiveness. This is quite definitely the reason why gmail doesn't always use https (though it, unlike some other web sites, doesn't refuse to use it). Interestingly enough, Google just added a feature to GMail to force secure connections: http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html Jeff
Re: Multiple DNS implementations vulnerable to cache poisoning
On Tue, Jul 8, 2008 at 8:26 PM, Lynda [EMAIL PROTECTED] wrote: Audio of Dan's press interview: https://media.blackhat.com/webinars/...conference.mp3 Actual URL: https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conference.mp3 Jeff
Re: [NANOG] Broken Link
On Mon, May 12, 2008 at 12:11 PM, Owen DeLong [EMAIL PROTECTED] wrote: Apparently Thomas doesn't let you just publish a link to bills... The link I published doesn't work. That's because the automatic link detection in most readers doesn't consider the trailing : as part of the link. Be sure to copy the trailing : when loading the link in your web browser. http://thomas.loc.gov/cgi-bin/query/z?c110:H.R.5994: The other bill is H.R. 5353. Same thing: http://thomas.loc.gov/cgi-bin/query/z?c110:H.R.5353: Jeff ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
