[00:03] tomreyn: ^ [00:04] geigerCounter: you can configure what systemd does to shut down a service [00:04] How do I do that beyond specifying it in ExecStop? [00:05] geigerCounter: there is also KillMode [00:05] mwhudson: Tell me more/link me to docs? [00:05] geigerCounter: man systemd.kill [00:05] geigerCounter: but i think execstop is what you want here [00:06] geigerCounter: you need your execstop script to wait for the process exit though [00:06] hm sounds like you are trying that [00:07] so what you are doing _should_ work, i don't know off hand why it would not be [00:07] Yeah. [00:07] I don't either really. Today is my first day ever making a systemd unit. [00:08] What happens when I use service stop is the java process just dies and then since it has no more child processes, screen exits normally. This isn't the expected behaviour. [00:09] geigerCounter: sorry, i lost track there. [00:09] It should push 'stop\n' to the screen and the server's shutdown sequence should begin. [00:09] Instead of just dying. [00:09] geigerCounter: did you look at the KillMode option? [00:10] Looking at it now on the suggestion of mwhudson [00:10] also, that's not really usual or normal way services behave. essentially you want systemd to start your screen as an oneshot "service" and forget about it. then you deal with your screen and minecraft manually. [00:11] this situation has been asked about before and the only answer is: open a bug report to minecraft devs and have them build proper service management controls into the daemon, namely respnding properly to TERM or QUIT signals. [00:12] There is no daemon. It was never intended to be run this way. It's intended to be run as an interactive console application using Java's console tools with stdin and stdout. [00:12] I want to run it *as* a daemon, using screen. [00:12] even systemd, the greatest controversy since Linus began his hobby, expects services to understand these signals. [00:12] Although yes, it should learn to respond to signals correctly. [00:12] >_< [00:13] geigerCounter: perhaps you can whip up some stdin command injection from a shell script exec'd via ExecStop [00:13] That's basically what I'm doing using screen's "stuff" command [00:13] use KillMode=none so it doesn't care about killing unresponsive processess (which this essentially is) [00:13] maybe think of some other (more common, maybe in ubuntu) java processes which might have the same issue and see whether a better solution was found there. [00:13] Which allows you to "stuff" characters into a detached screen as though you were typing it in yourself. [00:14] But the problem is systemd isn't paying attention to what I asked ExecStop to do. [00:14] Will try that and report back. [00:14] systemd will normall send a KillSignal (TERM by default) and if the process doesn't quit in TimeoutStopSec, it'll KILL It and all the kids. modulo KillSignal and ExecStop existing [00:14] sorry, modulo KillMode [00:14] sounds sane to me. [00:15] Oh I see. So that's probably part of the problem. I have my timeout set too low. [00:15] geigerCounter: read the systemd.kill manpage [00:15] I... rookie mistake. [00:15] I'm reading it. [00:15] Thank you. [00:15] :) [00:17] geigerCounter: also the first paragraph for ExecStop= entry in systemd.service(5) manpage [00:18] it explains what's going on exactly, and which value of KillMode you need (none) === cpaelzer__ is now known as cpaelzer [07:06] Good morning [08:14] cpaelzer I got a build failure for amd64 (but not the other archs), but it wasn't a build error. The build process and tests completed, then [08:14] Build killed with signal TERM after 150 minutes of inactivity [08:14] E: Build failure (dpkg-buildpackage died) [08:16] kstenerud: well this could be a real issue (background processes hanging or such) [08:17] kstenerud: but TBH most likely it is something awkward, you can ask the ops if soemthing known happened or just hit rebuild on your build [08:17] ok === ykarel_ is now known as ykarel|lunch === ykarel|lunch is now known as ykarel [12:08] good morning [12:47] ahasenack: I'm just not sure what would cause this kind of issue... It's a bug where php was closing file descriptors before a call to curl finished [12:48] and if it's testing whether a crash occurs or not, why would the entire testing rig die? [12:48] kstenerud: I'd try to run that test in isolation [12:48] kstenerud: well, it dies due to a timeout [12:49] side "A" is talking to side "B", side "B" crashes, side "A" doesn't notice and keeps waiting [12:49] It dies like this: [12:49] TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt] [12:49] E: Caught signal ‘Terminated’: terminating immediately [12:49] Then the calling process times out [12:49] check that test in isolation, is my suggestion [12:50] yeah I'm running an sbuild locally. If it crashes I'll shell in and see what's up [13:33] jamespage: coreycb: would it be possible to get an updated erlang version into UCA for xenial? like possibly the one from bionic? see the latest comments in https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1783203 [13:33] Launchpad bug 1783203 in rabbitmq-server (Ubuntu) "Upgrade to RabbitMQ 3.6.10 causes beam lockup in clustered deployment" [Undecided,Confirmed] [14:24] So when I run the build locally, it works :/ [14:32] Hey all. I want to setup internal dns in my classroom. I have an LTSP server running and dnsmasq is installed. I have a separate server acting as my gateway running isc-dhcp server. [14:32] I ultimately want to be able to access servers using fqdn internally like LTSP-Server.foo.local [14:32] I know very little about setting up dns. Any help? [14:37] JuJUBee, you can either set up DNS on your gateway, or on your LTSP server. Then set isc-dhcp to advertise the DNS server's IP [14:39] lordcirth, dhcp currently advertising 2 dns servers (open dns), can I just add the third IP of my dnsmasq machine? [14:40] JuJUBee, you could, but if you want them to always use your DNS server, you should probably set only that. [14:44] lordcirth, but if I only want to get to public sites, don't I need external dns servers? [14:44] JuJUBee, your DNS server should be configured to use those external DNS servers itself, for anything it doesn't manage. [14:46] So this seems far beyond my expertise. I was hoping it would be a fairly simple configuration [14:48] JuJUBee: the link I gave you shows you how to setup bind9 [14:48] JuJUBee, it is fairly simple. DHCP points clients to your dnsmasq. dnsmasq answers for .local, and for everything else, does a lookup to the outside and caches it. [14:55] leftyfb, bind kind of intimidates me. [14:56] lordcirth, I need to see how to do that in dnsmasq. I will read on it. [14:56] JuJUBee: and it will continue to intimidate until you try it, then it won't :) [14:58] leftyfb, I do have that link open and have been reading it along with dnsmasq setup. dnsmasq seems more appropriate for my simple needs. I just don't want to misconfigure bind and let the nastys in or prevent appropriate requests from getting out... [14:58] abusing .local isn't a good idea but maybe that was just a made up example [14:58] JuJUBee: this DNS server should NOT be accessible to the internet. Regardless of which solution you go with. [14:59] sdeziel: abusing? [14:59] leftyfb: .local shouldn't be used for internal purposes other than mDNS [14:59] sdeziel: why is that? [15:00] leftyfb: https://serverfault.com/questions/17255/top-level-domain-domain-suffix-for-private-network/937808#937808 [15:01] leftyfb: systemd-resolved chokes on .local names unless you configure it in a special way [15:01] sdeziel: it's been working on my local network for about a year now [15:01] leftyfb: do you also provide something.local as your search domain? [15:02] yes [15:02] leftyfb: that's why [15:02] leftyfb: this enables the special handling of .local by systemd-resolved [15:02] leftyfb: but normally .local is reserved for mDNS [15:02] oh wait, sorry. No. I only append .local [15:03] so .local [15:03] works just fine on my network. I can resolve everything locally [15:03] leftyfb: yeah, as long as local is in the search domain, systemd-resolved will try to accommodate for this abuse [15:04] leftyfb: as an experiment, drop local from you search domain, restart systemd-resolved then try to resolve .local, should fail [15:04] of course it will. Unless I have avahi/bonjour setup on every client [15:06] in theory, resolvers shouldn't attempt mDNS resolution when there are 2 labels with the last one .local but that is not implemented everywhere [15:06] that's why it's best to leave .local and everything under it reserved to mDNS [15:07] leftyfb: you said off course it would break without the search domain but that's only true for the .local domain... any other domain would have kept working [15:09] sdeziel: how would that work? If you have a local .home as your local domain and you try to ping hostname.home without having home as a search, how would it know to append that tld? [15:09] leftyfb: when you "ping hostname.home" no search label is appended because you provided one already [15:10] https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html then search for ".local" it explains it with all the details you'd want :) [15:10] sdeziel: and you said in the test, remove the search label. Obviously it would fail when you do that [15:11] leftyfb: the search domain is used to tell systemd-resolved that you are abusing .local and to back down on mDNS [15:11] oh sorry, my post above was wrong. %s/ping hostname.home/hostname/g :) [15:11] > Note that by default lookups for domains with the ".local" suffix are not routed to DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server and interface [15:11] from the above link [15:12] leftyfb: well, if you refer to the shortname, then of course it requires a search domain ;) === ykarel is now known as ykarel|away [15:13] > Note that today it's generally recommended to avoid defining ".local" in a DNS server, as RFC6762 reserves this domain for exclusive MulticastDNS use. [15:13] I'll think about changing it to something else at home :) [15:14] it's worth it if you can :) [15:14] after I figure out why my Unifi USG likes to disallow outbound DNS traffic around 6/7am requiring a reboot a few times a week :) [15:14] If only I had that insight years ago, I wouldn't have to leave with that damn foo.local at a client site ;) === ykarel_ is now known as ykarel|away [16:35] A fresh install of Ubuntu server 18.04.2. sudo apt install mysql-server. I run sudo mysql_secure_installation. I select No for everything except reloading the privilege tables and set my password. I cannot run: "mysql -uroot -p " to successfully login. What am I missing? [16:36] sorry, not space between p and the password [16:40] leftyfb: are you able to connect with mysql --defaults-extra-file=/etc/mysql/debian.cnf ? [16:41] negative [16:41] https://pastebin.ubuntu.com/p/Tr9Q8XdTGX/ [16:42] also fails if I specify credentials [16:43] also of note, I can login just fine with sudo and no credentials and every time I run mysql_secure_installation it says it's running with a blank password. It seems that utility isn't actually setting our password? [16:45] leftyfb: I just tested in a fresh container and cannot reproduce the root auth failure [16:45] I've been 'just testing" it all morning with fresh installs from the same flash drive I used to several install of other types of servers since yesterday. [16:47] https://paste.ubuntu.com/p/NDMV5D3YmJ/ root doesn't have any password despite having been asked for one by mysql_secure_installation, weird [16:49] yeah, that's a problem [16:50] I don't know about mysql_secure_installation [16:50] But you get socket based auth by default on the default install. [16:52] what does that mean for credential based auth? [16:52] I'm not sure. [16:53] I'd have to read the manual, etc. [16:53] It seems odd to be using mysql_secure_installation to me. [16:53] leftyfb: by default root has access through the Unix socket, without providing any password [16:53] I was under the impression the maintainer scripts did the right thing, and there was no need to run it. I could be wrong though. [16:54] sdeziel: as in, the root user. No supplying root as the user on the command line as a non-root user [16:54] leftyfb: correct, the root user which is why it worked for you with sudo [16:55] ok, and if I want to authenticate using a php script? [16:55] For the root user? [16:55] like I'm doing with the web app/db I'm trying to migrate from 16.04 to 18.04 [16:55] rbasak: yes, for the mysql root user [16:56] That seems dangerous. But if you insist, you'll have to set a root password. I'm not sure about how that interacts with socket auth (check the docs) [16:56] rbasak: it uses the auth_socket plugin [16:57] I'm assuming it's checking the UID of the user opening the Unix socket [16:58] https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1610574 [16:58] Launchpad bug 1610574 in mysql-5.7 (Ubuntu) "mysql_secure_installation/mysqladmin cannot set password when auth_socket is enabled" [Low,Triaged] [16:58] a stock install: https://paste.ubuntu.com/p/t4JRNffHjR/ [16:59] looks like I have a workaround I can try [17:01] "Also note that mysql_secure_installation is largely redundant for a fresh 5.7 installation" [17:01] redundant how? What's the replacement? [17:02] What are you expecting it to do for you? [17:02] set the root password [17:03] So just set the root password then: sudo mysql -e "ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' BY 'mypass';" [17:03] there's other things you can config as well, but that's my main use case [17:03] (frmo the bug) [17:03] yeah, I'm going to try that now on another fresh install [17:04] Perhaps we should stop shipping mysql_secure_installation to avoid misleading users into thinking it's useful. [17:04] Though that might be overkill because there are users who use mysql without the maintainer scrip tmanagement. [17:05] BTW, you can do that if you want. Just use mysql-server-core-5.7 and operate mysql yourself directly. [17:06] That works [17:21] does ubuntu support php 7.0? I think 7.0 is eol [17:22] DammitJim: on 16.04, yes [17:23] TY [17:23] DammitJim: upstream declared it EOL but Canonical will keep backporting security fixes to it, like it does for 5.5 on previous Ubuntu versions [17:23] ty [17:25] how do I determine if canonical supports a piece of software [17:25] say, I'm looking at the fact that I installed nginx [17:26] how do I know if it came from main or universe or a different repo? [17:27] DammitJim, apt show nginx | grep Source [17:28] so, multiverse is NOT supported by Canonica, right? [17:29] correct. Also things in multiverse usually have licensing issues [17:30] actually, I just looked at say mongodb and we are using the mongodb repo [17:30] what a mess [17:30] Nothing wrong with using upstream repos, as long as they are well supported. [17:30] I have HAProxy 1.7 from PPA in production. [17:31] but 1.7 is not end of life [17:32] I'm trying to keep track of what software needs to be upgraded because it's going to be end of life [17:32] Oh I see [17:36] ubuntu-support-status --help [17:39] lordcirth: I disagree. Using third party apt repositories is fundamentally broken and can break your system, even if well maintained. [17:39] But I appreciate that many people use them anyway. [17:39] rbasak, so is not having the software you need. [17:40] Sure [17:40] But they should understand the risks. [17:40] It's more stable to run an Ubuntu LTS + upstream-maintained stable release than any other option. [17:40] I am happy that HAProxy 1.8.8 is in 18.04, so I don't need a PPA anymore [17:41] In particular I'd strongly recommend against attempting a release upgrade if a third party package has been on the system. [17:41] I just don't do release upgrades. nuke and pave [17:41] The other thing that goes wrong is experimentation, so in production it's essential to have prepared an automated deployment [17:44] ubuntu-support-status --help? [17:44] OMG [17:44] that's huge! [17:46] Yeah, pretty cool [17:50] ubuntu-support-status reports odd things here. libwoff1 is said to be supported by Canonical for 3 years yet it's in main [17:56] wich ubuntu version are you on sdeziel [18:01] same on bionic here: libbrotli1 libwoff1 3y [18:03] lotuspsychje: 18.04 [18:03] lotuspsychje: yeah, same 2 packages in main that are reported as support for 3y only (instead of 5y) [18:04] oh I see what happens [18:04] those packages started in universe then were MRE after 18.04 release [18:04] ah [18:05] still, I don't see why they wouldn't get the full 5y support, looks like a bug in ubuntu-support-status [18:05] if you report, ill affect :p [18:07] how nice of you :P [18:08] i just want a cookie [18:14] lotuspsychje: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1820329 [18:14] Launchpad bug 1820329 in update-manager (Ubuntu) "ubuntu-support-status wrong support period for packages that were MRE during a release's life" [Undecided,New] [18:14] sdeziel: affected mate [18:18] sdeziel: you think it would differ with someone with the hwe kernel? [18:20] lotuspsychje: I wouldn't expect it to be different for those 2 libs but maybe for the hwe packages themselves since they've never been into bionic/main, only bionic-updates/main [18:20] kk [18:21] OMG, the things one doesn't know [18:21] ignorance is bliss! [18:21] I had no idea vim-nox was no longer supported! [18:22] DammitJim: I too was using vim-nox but have since moved to plain vim that's in main [18:23] I use neovim [18:23] new vim? [18:23] neovim? [18:23] hhhmmm [18:24] It's good. Some features have actually been backported to main vim. [18:58] is eol of ubuntu 14 at the beginning or end of APril? [18:59] DammitJim: April 25th, 2019 [18:59] is it always on the 25th? [19:01] Canonical seems to have a thing for Thursdays but other than that, I think the EOL date can vary [19:01] DammitJim: 14.04 will not be officially EOL but will transition to ESM (paid support) [19:02] Watched Popey's talk on snaps @ SCALE 17x. I couldn't disagree more on reasoning not to allow custom snap repos. What if a company wants to package their in-house, not publishable, apps as snaps in order to have a homogenous toolset and not a quagmire of snaps and dockers. Isn't that enough of a reason to allow custom repos? [19:03] blackflow, well, what was his reasoning? [19:03] I only gave one reason [19:03] who'd want to use snap on a (production) server anyway? [19:04] lordcirth: that allowing so would then cause the same issues PPAs have|had -- undiscoverability of programs published in custom repos [19:04] It's entirely possible to do the use case you describe [19:05] https://docs.ubuntu.com/snap-store-proxy/en/ [19:05] popey: yes but not with a repo, it'd have to be uploaded manually and handled --dangerous'ly [19:05] sdeziel: in bug 1820329 , do you actuall ymean MIR, not MRE (which was replaced by SRU, as far as I can tell)? [19:05] bug 1820329 in update-manager (Ubuntu) "ubuntu-support-status wrong support period for packages that were MRE during a release's life" [Undecided,Confirmed] https://launchpad.net/bugs/1820329 [19:06] tomreyn: right, I wanted to say MIR [19:06] popey: btw the vid linked from LINUX Unplugged, has bad audio and is missing segments. Is there a better one of your talk? [19:06] not that I'm aware of [19:06] I didn't even know it was streamed / recorded until afterwards. [19:06] sdeziel: a member tested it on 19.04 also with this result: libbrotli1 libwoff1 is shown as supported for 9 months (Jan 2020) [19:07] sdeziel: thanks for clarifying, i was just on a journey trying to understand what those different abbreviations mean (and got help there, so now i know) [19:07] lotuspsychje: 19.04 as a whole has 9 mo of support [19:07] sdeziel: allright, so not relevant for this bug right? [19:07] popey: ah, k. btw that link is about proxying the official snap store, or am I missing something in that? I was thinking about a completely custom store a company could use in-house on their servers [19:08] lotuspsychje: I don't think [19:08] popey: good talk btw (even though I disagree on that little point about snap store) [19:08] blackflow: that's right. the proxy along with a brand store effectively gives you that [19:08] thanks [19:09] We have customers who have an enterprise proxy as a frontend to their own brand store, which they control the content of [19:09] this might not be an ubuntu question, but more of a server question [19:09] is there anything I should consider with regards to a max amount of services that a server runs? [19:09] I have RAM and CPU if needed [19:10] these are java processes [19:10] any input from any of you? [19:10] DammitJim, resource contention, effect of a reboot, security [19:10] popey: is that available to non-advantage users? I can't seem to find anything about it in those docs [19:10] DammitJim: depends on the -Xms/-Xmx params you want to give to those JVMs I guess [19:10] that depends on how many resources those services need [19:10] DammitJim, are these diverse services, or just a bunch of instances of the same? [19:11] diverse, but similar in business logic [19:11] DammitJim, Consider running them all in unprivileged containers with resource quotas [19:11] Then you can reboot them independently, they can't spin out of control and eat all resources, etc [19:11] thanks... those are all good points [19:12] blackflow: the proxy is installable - it's a snap ;). There are indeed projects which have brand stores, which don't have UA [19:12] We use LXC containers on big IAAS hosts, all controlled by Salt. works pretty well. [19:12] when you say unprivileged containers, do you mean their own JVM? [19:12] I'm using salt, too, but not to that leevl [19:12] DammitJim, no, linux containers, ie LXC / docker [19:12] level [19:12] OS containers [19:13] unprivileged LXC containers means that uid 0 (root) in the container actually maps to uid 100231 on the host, who doesn't exist and has no permissions. [19:13] https://en.wikipedia.org/wiki/Container_(virtualization) [19:13] privileged containers have no such mapping, so any hostile or compromised process that is root in the container can trivially break out [19:13] lordcirth: Salt control on a completely isolated vlan, or is it publicly accessible? We rent servers with several providers and thus the control channel would have to traverse public networks. Something I am totally not comfortable with. [19:14] oh, these don't run as root either [19:14] blackflow, in this case, an internal, though not immensely locked-down, network [19:14] blackflow, ours is isolated vlan [19:14] yeah [19:14] DammitJim, yes, but if someone exploits your java app, then escalates to root, they will only be root in the container. [19:15] blackflow, the only weakness Salt potentially has is when a minion first connects to the master - it trusts the master's key on first connect. If you don't trust the network, preseed all your minions with the master key, and no more holes. [19:17] lordcirth: it's no that that I'm worried much about, it's the fact that the master would we a publicly accessible server -- because we rent them. I mean that one machine would be the gateway to all the servers. One point to compromise and then everything is. [19:17] would *be [19:18] blackflow, ah, you are worried about the master being compromised. Well, one thing you could do is require a VPN to reach the master. [19:18] It would take a bit more preseeded setup, but you could require new minions to establish an 2-way auth'd VPN, then connect to Salt over it. [19:18] lordcirth: it's still one publicly accessible port. one vuln in the network stack and poof... [19:19] but then.... the same vuln could be used on all teh servers individually... moot point. I worry too much. [19:19] blackflow, that vuln in the network stack would affect all of your minions... [19:19] yeah [19:19] we worry too much [19:19] There's only so much you can do while being connected to the internet :) [19:19] and you know what the worse part about that is? the day you get tired of worrying ('cause that happens to me), that day is when I make very poor decisions [19:19] But props for being paranoid :) [19:20] yah :) [19:20] healthy paranoia is good [19:20] healthy paranoia is good, but it's not easy to achieve... gotta make sure to have a good balance [19:20] that balance is hardest to achieve [19:22] at the very least I manage to convince everyone in the company that public clouds and VPS'es are a big no-no, in the post Meltdown+Spectre world. [19:24] talking about being paranoid ... I am taking over a system (a few virtual ubuntu servers) where the prev sysadmin did a apt upgrade without waiting a while and checking the packages for bugs or doing any kind of test ... would you continue that practice? :-) [19:25] that's a good question... how does one deal with that supaman ? [19:25] depends on how paranoid you are ;-) [19:25] with ZFS snapshots of course. [19:28] I'm not for that kinda stuff [19:28] we do run the production environment in a virtual lab and test our applications [19:28] but I don't go looking for bugs in the updates [19:32] I can't remember the last time that an apt upgrade broke something. Once or twice a full-upgrade kernel update did, but you need to reboot to notice that, and then you just reboot back to the old one [19:58] you dont need ZFS snaps if you have good backups [19:59] Ussat, best thing is to take ZFS snapshots, and then backup the snapshots. Prevents smearing (I forget if there's a more common term) [20:00] naaa...we dont and wont use zfs [20:00] The snapshots are instant and make sure your backup doesn't get different files at different times as it chugs along [20:00] no need [20:00] Ussat, so, how do you detect bitflips? [20:01] in all the years I have been doing this, I have NEVER had an issue with that [20:02] Ussat, that you know of [20:02] That I am sure of [20:02] So, if a bit flipped somewhere on one of your drives, you are quite sure you would get an email about it? [20:03] Just a few months ago I suddenly got 30 checksum errors on each of 3 drives in a raidz. No idea why, maybe a power surge. Didn't matter, ZFS fixed it all [20:03] Granted that wasn't on enterprise hardware, but that's just a difference of degree. [20:04] I dont use non-enterprise HW at work [20:04] "just" a different of degree..... [20:05] so you are less likely to get bitflips. Not 100% assured. [20:05] nothing is ever 100%...ever [20:05] ZFS decreases your odds of a bitflip by several orders of magnitude, which is enough for me. trusting hard drives isn't good enough for me. [20:06] all my data I am concerned about is stored o a SAN, if a VM image is corrupted, no big deal..... [20:07] We use a real enterprise SAN, sot a bunch of commercial disks off the shelf with a fancy FS on it [20:08] I trust ZFS a lot more than a "real enterprise SAN" blackbox [20:08] to each their own [20:08] I dont [20:08] Not to mention the cost and vendor lock-in [20:09] lordcirth: hear hear [20:09] guess some people are too lucky and never had a failure [20:09] Oh I have had failures...sure......none of them crippling [20:09] Obviously a good SAN is better than what a lot of people do... [20:09] My systems are very critical..... [20:09] Some people run production data on commercial drives with just RAID.. ow. [20:10] a lot of people use a good SAN [20:10] ZFS snapshots (sent offsite) are godsent for backups. quick, atomic, with data integrity checks. [20:10] Not in my industry they dont [20:16] "a good SAN" is not replacement for offsite backups. ZFS (or any other CoW) is orthogonal to SAN. Your SAN can be powered by ZFS. So I don't get your point. [20:17] A SAN could be powered by ZFS, but are generally powered by blackbox magic [20:19] Who said I dont have offsite backups ? [20:20] I never said that, I have a very robust backup solution w/offsite backups [20:21] Yes, I assumed you did. [20:21] well you seem to have put ZFS in a opposition to SANs. [20:22] blackflow, he just said he doesn't need ZFS because he has a fancy SAN. Doesn't mean you couldn't somehow have both. [20:22] which is wrong really, they're orthogonal. So is this: "20:58 < Ussat> you dont need ZFS snaps if you have good backups" --- but ZFS snapshots _are_ good backups, when you `zfs send` them offsite [20:23] doesn't make sense to put ZFS snapshots and good backups in opposing relationship. that's like saying "You don't need a filesystem if you have good backups" [20:23] incorrect, but thats ok you do what you want, I do what we do [20:23] and you would likely want to use some sort of snapshot on that SAN too... [20:23] JanC, the SAN is mirrored between sites [20:23] to make backups [20:24] NO...not to make backups [20:24] I am not going to explain how our san enterprise works...it works quite well and is very efective [20:24] so how do you guarantee data consistency on you backups? [20:24] Its not just a bunch of off the shelf disks and consumer grade PCs .... [20:27] Ussat: not sure which part is incorrect. perhaps you don't know what ZFS is? a snapshot is a backup per se. it's a copy of data you can revert to. you can back your data from it. it becomes _good_ backup when you ship it offsite. you might not like it, that's okay. use something else, fine, but how is all this "incorrect"? [20:27] per se [20:27] a snapshot is not a backup [20:27] ^^^ [20:28] but you need it to make consistent backups [20:28] yes it is, it's just not good enough if it's local [20:28] you can ship it elsewhere and it's still a zfs snapshot. in a physically different location. [20:29] maybe y'all don't know about the `zfs send` feature. it's made to send snapshots to external pools. and `zfs receive` to bring them in from external pools. how's that not a backup. [20:30] I know what it is, and when you do that you have a proper backup indeed [20:30] I am quite aware of them, and we looked at them and rejected them [20:30] arguing over the semantics of what is and is not a 'backup' is irrelevant when you agree on what they are [20:30] it's okay if you don't like them. but fact remains they _are_ useful backups. [20:30] Not in our case [20:31] What is special about your case that ZFS is not sufficient? [20:31] Correct [20:31] We evaluated it, and it doesnt meet pur needs [20:32] I am interested to know in what way ZFS fell short of your needs. [20:32] I'm dying to know too [20:33] I dont need to justify my descisionsto you.......as soon as you start cutting my paycheck, then that is a different matter [20:33] lol [20:33] It did not meet our needs [20:33] I don't see any reason to suddenly turn so hostile... [20:33] Thats hardly hostile [20:33] why do you think that's "justifying"? this is a discussion forum. if you don't like it you can always /part [20:34] but I know what it is. you just have no idea what you're talking about. so lashing out is best defense to hide ignorance. fine by me. [20:34] blackflow, while that is possible, I don't think you have sufficient evidence to assume that. [20:34] Yes, yes I do, we evaluated it and it did not meet our requirements [20:34] oh I do. seen that type too often. [20:34] armchair "admins" who feel threatened when asked to explain their use case. [20:35] armchair admins...um sure [20:35] yup. [20:36] Ussat: it would be useful to know in (roughly) what way it didn't meet your requirements [20:36] OK, and you are obviousely the expert......you have no clue what industry or what the requirements are, but you can make that assumption. You seem to think that ZFS will meet all requirements [20:36] Ussat, no, we asked what requirements it didn't meet, and you refused to answer [20:36] Which usually means you don't know. [20:36] any word yet as to this supposed horribad vulnerability that made scroogle and fakebook down their networks for "disruptive, lengthy, unannounced but totally planned and routine maintenance"? [20:36] There are some requirements ZFS can't fulfill. [20:36] lordcirth, ir which means it may be none of your business [20:37] Ussat, and yet you are still here arguing about it? [20:37] If you have an NDA, say so. [20:37] Ussat: you don't know how to read either. I said several times it's fine if you don't like it or if it doesn't work for you. I never said ZFS _must_ meet your requirements. [20:37] I am in a highly regulated industry, and ZFS did not meet the requirements [20:37] that's fine. so we asked what does. [20:38]