Server Version - The downloaded file has been named Manager.zip instead of ManagerServer-Linux-x64.zip
Also it appears that the downloaded file if unzipped is not healthy - Manager application does not work. Looks like a Windows Version is being install on Linux?
@compuit, did you get it sorted? It took me a couple of goes to get it right. It wasn’t obvious but became more evident if you started looking at the error logs. There are some subtle changes that we need to make and a normal update is not going to work.
There has been a bit of work behind the scenes and manager no longer relies on mono on linux and mac, so the systemctl service file needs an update too. Now, Manager-Server is a stand alone binary and requires permission changes, and the aforementioned systemctl .service file edit.
Now for me, even after several attempts, fixing of the command line parameters of the systemctl .service file and execution permissions for the server binary, I still couldn’t get it to work, it just continually crashed.
What I needed to do just once was start it from the command line itself (and shut it down) and then re-start the service and I was up and running.
It does kinda looks like it’s the windows version, and it kind of is, it’s a native .Net 5 Core binary, but it is a binary for linux (or Apple as the case may be). As a result, it is executed natively and the .Net files are located in the same directory.
In essence:
chmod a+x ManagerServer/etc/systemd/system/manager-server.service (see below)systemctl daemon and restart the servicesystemctl manager-server.service file:This is likely what you missed.
for the average server, change:
ExecStart=/usr/bin/mono /usr/share/manager-server/ManagerServer.exe
to:
ExecStart=/usr/share/manager-server-20976/ManagerServer
note: removal of /usr/bin/mono, and .exe at the end of server name
My server settings are a little custom, but essentially the same with custom port and database locations:
# old:
ExecStart=/usr/bin/mono /usr/share/manager-server-{version}/ManagerServer.exe -port {custom_port} -path {custom_path}
# new:
ExecStart=/usr/share/manager-server-{version}/ManagerServer -port {custom_port} -path {custom_path}
The full usual instructions are still at the same location (and always hard for me to find, so I do like to link it):
https://www.manager.io/server/installation/ubuntu/
The new new install instructions have already been updated and are on the server install instructions page (you’ll note they are a little different). If you go through the complete install process, it should work. you’ll notice the systemctl manager-server service is a little different, and that’s where it is failing (or it was for me) and whatever the error was that required me to start it natively before being run as a service. I’m still not sure what that was about but haven’t had the time to delve any further.
Good luck
* for me, this is the first place where things broke down, because I don’t use the default locations and hence I needed to dig a little deeper. What I do is create a new folder for each version, including the databases, do backups, copy both the database files and service utility files to the appropriate locations and edit the systemctl service file, pointing to the new locations and apply new port settings. I have scripts for this, but they failed due to other changes (eg, source file location, file name, extraction, permissions, service, etc, etc).
This change has broken my upgrading scripts both in sourcing the latest version and files to extract (and one to edit). There’s not much point in re-writing them at the moment as it looks like he’s going to change the format of the files again so I’d need to seek out the new names at that point. This is according to:
Mmm
That sounds like a complicated way of doing things.
I use a constant location / address for the active version but version specific names for any archives.
But the converse is clearly possible.
Cheers guys … fortunately I first test updates in a test environment. Also I have not looked at the issue again however these are the instructions that appear to be misleading to me. See: Ubuntu | Manager
I suspect they will need to be updated?
Also how will these changes impact the specified path to data files, will the switches still apply?
eg. ExecStart=/usr/bin/mono /usr/share/manager-server/ManagerServer.exe -path /media/network/nas/manager -port 8080
OK I made those tweaks all go in test environment … Cheers
The instructions were updated 2 days ago.
Yes but there is a mistake - You cannot: Then unzip downloaded ManagerServer-Linux-x64.zip using following command
unzip /usr/share/manager-server/ManagerServer-Linux-x64.zip -d /usr/share/manager-server
Why because ManagerServer-Linux-x64.zip has been saved as Manager.zip
As written in first post.
Hi @compuit best practice is always do a test update or backup before you update production environment.
I would like to confirm that @d3mad recommendation works to upgrade to the latest version…follow;
wget https://github.com/Manager-io/Manager.zip/releases/latest/download/ManagerServer-Linux-x64.zip -O /usr/share/manager-server/Manager.zip
unzip /usr/share/manager-server/Manager.zip -d /usr/share/manager-server
chmod a+x ManagerServer
(run this on the installation folder)
printf "[Unit]\nAfter=network.target\n\n[Service]\nLimitNOFILE=1048576\nExecStart=/usr/share/manager-server/ManagerServer -port 8080\nRestart=on-failure\nStartLimitInterval=600\n\n[Install]\nWantedBy=multi-user.target" | sudo tee /etc/systemd/system/manager-server.service
systemctl daemon-reload
systemctl restart manager-server
Ok, I see what you’re saying now in rereading your first post and in light of what you’ve posted there.
It was saved as Manager.zip and how did that happen exactly? Did you click a hyperlink and download a file that was saved as that name, or did you use the command line wget method? (Or did you save it from somewhere else?)
The instructions have changed a bit over time, but the current instruction from the link you provided is:
wget https://github.com/Manager-io/Manager.zip/releases/latest/download/ManagerServer-Linux-x64.zip -O /usr/share/manager-server/ManagerServer-Linux-x64.zip
unzip /usr/share/manager-server/ManagerServer-Linux-x64.zip -d /usr/share/manager-server
What @PFIVE posted above will also work because in their instructions, the saved zip file name in both commands have been changed. That is the last file name on the first line and the first/only file name on the second line. As long as they match, you are working on the correct file.
Perhaps, and likely, the instructions may have had the old file name present, or your command line history may have (or script or whatever).
Regardless, following the instructions now should work. Regardless, I would suggest starting again, re-enter the download wget line and unzip.
I use to do that as well, but at the OS level I never knew what version was running, so I canned the generic naming structure about a month ago. Now, I don’t have anything in /usr/share/manager-server/ and everything is delineated by a version number.
Having version numbers in folder names, I am now also able to tell when I started using a particular version, by folder creation date.
Within systemctl I enable/disable the server(s) as required. They are usually all disabled except for the current one, and anytime I need an old one I just start it up and jump to that port. I’ve got it down to a fine art now, except that my scripts have broken countless times over the years, mostly with file name, cloud service, or deployment (eg, AppImage, vs zip, vs dmg, vs tgz etc) changes.
And it’s helped me to learn a lot too!
I don’t often access from the outside anymore, I either work within my network at home or on the MBP (via desktop version and a backup, but that’s not usually for entry, more analysis and reporting). If I did want to avail the server from outside (and I have on the odd occasion), I use ssh port forwarding and log in that way. I could just edit ports in the firewall, but I really don’t need that sort of access these days. Not usually anyway.
One thing I’ve wanted to research is (my term and probably incorrect at that) loopback ports and being able to redirect an inbound port to the server, to a new specific port. Using dnsmasq , iptables, or similar, but again, more as proof of concept and not as a production requirement. Again, this could be done in the firewall too
I use the command line method and totally follow best practice. The Instructions have been corrected since raising the issue. The ManagerServer-Linux-x64.zip file has been written in along with other instructions which have been added, like PFIVE pointed out, thank you. This case can be closed now, cheers gentlemen.