ZeroTier RPM Installer Script Failing
-
So here is my question. I have ZT installed on a CentOS box from prior to the RPM process existing. If I install the RPM, will it update it? or install a second instance?
-
And the answer is, it updated. I expected this since it was an RPM download and install. But you never know for sure if a developer did this the right way.
root@pbx:~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 02:15:5d:67:37:08 brd ff:ff:ff:ff:ff:ff inet 10.254.0.24/24 brd 10.254.0.255 scope global eth0 inet6 fe80::15:5dff:fe67:3708/64 scope link valid_lft forever preferred_lft forever 3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether e6:5e:53:f7:06:75 brd ff:ff:ff:ff:ff:ff inet 10.254.1.24/24 brd 10.254.1.255 scope global zt0 inet6 fde5:cd7a:9e1c:8beb:e699:93b5:d8eb:980f/88 scope global valid_lft forever preferred_lft forever inet6 fe80::e45e:53ff:fef7:675/64 scope link valid_lft forever preferred_lft forever root@pbx:~ $ zerotier-cli -v 1.1.4 root@pbx:~ $ curl -s https://install.zerotier.com/ | bash *** ZeroTier One Quick Install for Unix-like Systems *** Supported targets for this script: *** MacOS (10.7+) on x86_64 (just installs ZeroTier One.pkg) *** Linux / Debian (wheezy or newer) on i386, x86_64, and armhf (Raspbian/jessie only) *** Linux / Ubuntu (trusty or newer) on i386 and x86_64 *** Linux / SuSE (12+) on i386 and x86_64 *** Linux / CentOS (6+) on i386 and x86_64 *** Linux / Fedora (22+) on i386 and x86_64 *** Linux / Amazon (2016.03+) on x86_64 *** Please report problems to [email protected] and we will try to fix ASAP! *** Detecting Linux Distribution *** Found RHEL/CentOS, creating /etc/yum.repos.d/zerotier.repo *** Installing zerotier-one package... Loaded plugins: fastestmirror, refresh-packagekit Setting up Install Process Loading mirror speeds from cached hostfile * base: ftpmirror.your.org * extras: centos.mirror.nac.net * piaf64: www.pbxinaflash.org * updates: mirrors.lga7.us.voxel.net zerotier | 2.9 kB 00:00 zerotier/primary_db | 3.7 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package zerotier-one.x86_64 0:1.1.4-1.el6 will be updated ---> Package zerotier-one.x86_64 0:1.1.8-0.1.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================================================================ Package Arch Version Repository Size ================================================================================================================================ Updating: zerotier-one x86_64 1.1.8-0.1.el6 zerotier 266 k Transaction Summary ================================================================================================================================ Upgrade 1 Package(s) Total download size: 266 k Downloading Packages: zerotier-one-1.1.8-0.1.el6.x86_64.rpm | 266 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : zerotier-one-1.1.8-0.1.el6.x86_64 1/2 error reading information on service newservice: No such file or directory error reading information on service newservice: No such file or directory warning: %post(zerotier-one-1.1.8-0.1.el6.x86_64) scriptlet failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm package zerotier-one-1.1.8-0.1.el6.x86_64 Cleanup : zerotier-one-1.1.4-1.el6.x86_64 2/2 Verifying : zerotier-one-1.1.8-0.1.el6.x86_64 1/2 Verifying : zerotier-one-1.1.4-1.el6.x86_64 2/2 Updated: zerotier-one.x86_64 0:1.1.8-0.1.el6 Complete! *** Enabling and starting zerotier-one service... *** Waiting for identity generation... *** Success! You are connected to port >redacted< of Earth's planetary smart switch. root@pbx:~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 02:15:5d:67:37:08 brd ff:ff:ff:ff:ff:ff inet 10.254.0.24/24 brd 10.254.0.255 scope global eth0 inet6 fe80::15:5dff:fe67:3708/64 scope link valid_lft forever preferred_lft forever 3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether e6:5e:53:f7:06:75 brd ff:ff:ff:ff:ff:ff inet 10.254.1.24/24 brd 10.254.1.255 scope global zt0 inet6 fde5:cd7a:9e1c:8beb:e699:93b5:d8eb:980f/88 scope global valid_lft forever preferred_lft forever inet6 fe80::e45e:53ff:fef7:675/64 scope link valid_lft forever preferred_lft forever root@pbx:~ $ zerotier-cli -v 1.1.8 root@pbx:~ $ -
ZeroTier hasn't been self-updating on Linux since very early versions. We found that many Linux users were using it on servers and really did not want software auto-updating itself independent of their scheduled use of 'yum' or 'apt'.
In 1.1.6+ we have finally developed real Linux packages and our own Linux package repository. The install script we created just adds that repo and installs the package, and once the repo is added it should auto-update along with other Linux packages when you do system package updates. This is expected behavior on Linux for a packaged app.
We also have people working to get this into Fedora/EPEL and Debian upstream but that's another matter, and many users might still prefer our repos since they will be updated more quickly.
MacOSX and Windows have auto-update functionality but we've been sort of gun shy about using it for the same reason. So far our policy has been to keep it around in case we ever have a critical security vulnerability that we need to force-patch ASAP. So far that has not happened.
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
ZeroTier hasn't been self-updating on Linux since very early versions. We found that many Linux users were using it on servers and really did not want software auto-updating itself independent of their scheduled use of 'yum' or 'apt'.
That's what I would want to.
-
1.1.8 is the current client, right? I'm "going around" updating the clients now.
-
@travisdh1 Are you adding the repo too?
-
@aaronstuder said in ZeroTier RPM Installer Script Failing:
@travisdh1 Are you adding the repo too?
Yes, I'm running the "more secure" method. It just worked on my CentOS7 box. The remote connection is so slow that even text updates sent over ssh take some time, waiting for that to confirm it's finished currently.
-
@travisdh1 said in ZeroTier RPM Installer Script Failing:
@aaronstuder said in ZeroTier RPM Installer Script Failing:
@travisdh1 Are you adding the repo too?
Yes, I'm running the "more secure" method. It just worked on my CentOS7 box. The remote connection is so slow that even text updates sent over ssh take some time, waiting for that to confirm it's finished currently.
Remember... tmux / screen are your friends... just in case you get disconnected!
-
@dafyre said in ZeroTier RPM Installer Script Failing:
@travisdh1 said in ZeroTier RPM Installer Script Failing:
@aaronstuder said in ZeroTier RPM Installer Script Failing:
@travisdh1 Are you adding the repo too?
Yes, I'm running the "more secure" method. It just worked on my CentOS7 box. The remote connection is so slow that even text updates sent over ssh take some time, waiting for that to confirm it's finished currently.
Remember... tmux / screen are your friends... just in case you get disconnected!
I'll have to head over latter today anyway, so I don't care so much if I loose my limited ability to connect/manage those things.
As it turns out, they install the new thing and wait for you to restart/reload the service. Everything worked (that one is on wheezy.)
-
@travisdh1 said in ZeroTier RPM Installer Script Failing:
1.1.8 is the current client, right? I'm "going around" updating the clients now.
As of yesterday, yes.
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
ZeroTier hasn't been self-updating on Linux since very early versions. We found that many Linux users were using it on servers and really did not want software auto-updating itself independent of their scheduled use of 'yum' or 'apt'.
Ah I knew I read that somewhere. Glad I'm not going crazy.
-
ZeroTier RPM 1.1.12 is out now.
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
MacOSX and Windows have auto-update functionality but we've been sort of gun shy about using it for the same reason. So far our policy has been to keep it around in case we ever have a critical security vulnerability that we need to force-patch ASAP. So far that has not happened.
So how would I enable an auto update on my windows clients? Is there some secret setting I can manually enable? Or is it only something you guys can push in emergency? ZeroTier is not available via Chocolatey and I have no other means to easily push an update setup at this time.
-
Right now it's a button we can push. There's a signing key we have that we keep in cold storage for it.
We'd like to revisit the update schedule at some point in the future since auto-updating quickly can be a desirable feature if it's done well. But it's very hard to do well, especially with an app that integrates with the OS the way ZeroTier does. ZeroTier has drivers, services, etc.
BTW we had a couple releases in a row over the last week since we were fixing minor issues with route management and default route override / full tunnel, both of which were new and non-trivial. Hopefully it's calmed down now.
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
Right now it's a button we can push. There's a signing key we have that we keep in cold storage for it.
We'd like to revisit the update schedule at some point in the future since auto-updating quickly can be a desirable feature if it's done well. But it's very hard to do well, especially with an app that integrates with the OS the way ZeroTier does. ZeroTier has drivers, services, etc.
BTW we had a couple releases in a row over the last week since we were fixing minor issues with route management and default route override / full tunnel, both of which were new and non-trivial. Hopefully it's calmed down now.
The problem is I have 32 devices all running 1.1.4 and I now need to upgrade them with no simple way to do it.
-
I thought there were simple ways of pushing MSIs to Windows machines. That's why we've worked really hard to keep the installer in MSI format even though it does a number of complex things that Advanced Installer keeps wanting to kick us into the EXE track to accomplish.
What's the current state of the art for managing software installs across Windows machine pools?
-
Also what do most sysadmins think about auto-updates? I know some are -- like in the Linux world -- against auto-updating software and want things to update on a schedule (for obvious reasons).
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
Also what do most sysadmins think about auto-updates? I know some are -- like in the Linux world -- against auto-updating software and want things to update on a schedule (for obvious reasons).
Linux I generally see as against because integrated updates are already inclusive. So the whole YUM Repo integration thing is perfect.
On Windows I generally see the opposite. Since there isn't an existing OS system for this built in, auto-updates from apps makes sense.
-
@adam.ierymenko said in ZeroTier RPM Installer Script Failing:
I thought there were simple ways of pushing MSIs to Windows machines.
In the enterprise doing this with GPO or other tools is possible. Sometimes in the SMB. But often in the SMB there isn't a unified network for this stuff and it isn't very practicable.
-
Hmm... we've wanted to rework updates for quite some time so maybe we'll do something with a setting.
Like I said it's very hard to do... you can fire off a background MSI installer but if it fails you are SOL. Google built an entire auto-update system for Chrome themselves because of this.
Windows software deployment is terrible. Of course Mac is not that much better... you have Apple's absolutely awful app store with its restrictions that exclude almost all interesting desktop software.
