#linuxcnc-devel Logs

Mar 27 2018

05:09 AM selroc: hello seb
09:55 AM jepler: now that I have a couple of scripts running that regularly interact with the DigitalOcean API, I notice when the API has downtimes...
04:30 PM jepler: cradek: what work are we waiting for to change the nameservers for linuxcnc.org to point at digitalocean instead of dreamhost?
04:30 PM cradek: uh I simply forgot about it
04:31 PM jepler: oh!
04:31 PM jepler: can you do it now/soon?
04:32 PM mozmck: What are the advantages of digitalocean over dreamhost? We are using dreamhost and keep having problems.
04:32 PM jepler: mozmck: the main reason I am advocating moving the DNS to digitalocean is that the DNS on dreamhost needs SWPadnos's credentials to update, and he's not around
04:33 PM jepler: mozmck: when you say you have problems at dreamhost, can you be more specific? DigitalOcean has been very reliable for me, but their pricing structure doesn't make actually moving the main linuxcnc website away from DreamHost's "unlimited everything shared hosting" fiscally feasible
04:34 PM cradek: jepler: looks like I can do it now. it's currently ns[12].dreamhost.com.
04:34 PM mozmck: I think email is the biggest thing - their email server seems to go down a bit.
04:34 PM cradek: what do you want them to be?
04:34 PM jepler: cradek: ns[123].digitalocean.com
04:34 PM jepler: mozmck: oh, linuxcnc isn't using DH for email at all
04:35 PM mozmck: But they also sent us a notice that they are killing processes from our website (wordpress with a commerce plugin and a bunch of others). They want us to upgrade to a much more expensive plan.
04:36 PM jepler: I don't recommend DO for email. You have to host and maintain your own mailservers, and you have no idea what kind of reputation the last owner of that IP had as far as sending spam. also, their IPv6 does not permit outgoing SMTP (and they have no plans to change that!)
04:36 PM mozmck: processes is probably the wrong word - scripts
04:36 PM jepler: at this point what we have on dreamhost is just dumb fileserving over http.
04:36 PM mozmck: I see.
04:36 PM jepler: but the unmetered transfer and disk space are great for that. We transfer around 1TB/week.
04:36 PM cradek: jepler: done
04:36 PM jepler: cradek: OK, cool!
04:37 PM cradek: jepler: then when exactly do you change the ns records in the zone?
04:37 PM jepler: cradek: the NS records in the zone at DO already/always said DO
04:38 PM cradek: ok perfect
04:39 PM jepler: hmmmm
04:39 PM mozmck: 1TB/week is a lot! We don't do near that.
04:39 PM jepler: the DNS SOA serial number
04:39 PM jepler: .. is lower at DO than it was at DH!
04:39 PM cradek: that ain't good
04:39 PM jepler: does that matter, other than for zone xfers?
04:40 PM cradek: hmm I guess I don't really know
04:40 PM jepler: (we don't exercise control over DNS SOA serial number, it's UNIX seconds at DO, looks like; and was date + "00" at DH)
04:40 PM jepler: g.root-servers.net is now serving up the right NS records!
04:40 PM cradek: I sympathize with the geek who decided to use unix seconds, but nobody does that
04:41 PM cradek: oh so it's probably fine? it's probably fine.
04:41 PM cradek: jepler: thanks for the reminder. sorry.
04:48 PM jepler: cradek: no problem
04:52 PM jepler: "Special circumstances may require this [incrementing] rule to be set aside, for example, when the serial number needs to be set lower for some reason." -- RFC1982
04:53 PM cradek: ha
04:53 PM cradek: so you should increase it, except for when you need to decrease it
04:53 PM jepler: yes
04:54 PM jepler: in that case you should take special care, the RFC goes on to state
04:54 PM jepler: .. you should "verify that ALL servers have correctly succeeded in following the primary server's serial number changes"
04:54 PM jepler: so I think this is really only a problem for zone transfers and secondaries, but are aren't switching any *secondary* that pointed at DH to point at DO
04:55 PM jepler: it's fine. the real problem will be if I botched or forgot any of the records
05:46 PM seb_kuzminsky: i updated theinfo on our DNS service and finally pushed the "Services and Responsibilities" document to linuxcnc/infrastructure.git
05:46 PM seb_kuzminsky: https://github.com/LinuxCNC/infrastructure/blob/master/services-and-responsibilities.adoc
05:46 PM seb_kuzminsky: huh, github renders asciidoc, i didn't know that
05:47 PM seb_kuzminsky: internal links don't work, oh well
05:50 PM jepler: seb_kuzminsky: thanks and thanks!
06:39 PM andypugh: Well I found out why reversing my axis made the PID tuning go crazy. I forgot to reverse the resolver velocity scale, so the D-term was doing exactly the wrong thing :-)