Files to replace on update
#1
Hi, I'm making a script for Linux, that I will put on a cronjob, that will check if the server is online every 5 minutes, if not, it will download the latest build from http://builds.cuberite.org/ , update the server and start it again.

I would like to know what files should I replace on update, or what files I should not change.

I will publish a guide, with the update script, the stop script and the cronjob, so people could use it.

The result should be 2 cronjobs, one that checks if the server is online and if not update it, and one that stops the server in case is running to update it every X days.

And about the stop script , it is possible from a bash script to echo some message into the server, to warn the online users that the server is going down for update?
   
Thanks in advance.
Reply
Thanks given by:
#2
Tigerw's Autoupdate Script is a bit outdated but has the right idea, and you could probably build on it.

https://github.com/tigerw/Cuberite-Autoupdate-Script

About your second question: It should be possible to attach your sender to the stdin of the server process and send a message into it. Named pipes, maybe? Or use screen, that's quite easy.
Reply
Thanks given by:
#3
(12-19-2015, 02:56 AM)bearbin Wrote: Tigerw's Autoupdate Script is a bit outdated but has the right idea, and you could probably build on it.

https://github.com/tigerw/Cuberite-Autoupdate-Script

Is based on his script, I took it modified it to support arm7l also, and added the rest of the code, but I have the same doubt, he only copies some folders and files, but not the binary for example, that's why I am asking, to see if there something missing that i need to replace, or just use his code as is.

Rigth now is working perfect replacing all files from the tar, the favicon is rewrited but in my case i don't mind as the rest works as it should, including plugins, worlds etc. I ask in order to make it available to other people that may want to preserve some things and to those hosting servers so they don't have to check every once in a while if the server is up or down and update it manually.

Thanks again.
Reply
Thanks given by:
#4
I got it fully working, it executes it on startup , every 5 minutes checks if the server is online, every 2 days it stops the server and updates it at 06:00 AM and I've made it available as a service in debian, so people could use "service cuberite start|stop|restart" for easy management.
Start and Restart uses the same script so it also checks for updates on restart or start the server.

Any clues about sending a message to the online users in the server to warn them about the server going to restart?

Thanks.
Reply
Thanks given by:
#5
How are you stopping the server? Are you piping in a message or sending a kill signal?

If you're sending a message then you can just send in "say message".
Reply
Thanks given by:
#6
(12-19-2015, 06:04 AM)bearbin Wrote: How are you stopping the server? Are you piping in a message or sending a kill signal?

If you're sending a message then you can just send in "say message".

Right now I'm just killing the signal to stop the server, i search for the cuberite detached screen pid and send a kill signal. I supposed there is a better way to stop the server, is a wip so I'm open to suggestions.
Reply
Thanks given by:
#7
(12-19-2015, 11:12 AM)Rekuen Wrote:
(12-19-2015, 06:04 AM)bearbin Wrote: How are you stopping the server? Are you piping in a message or sending a kill signal?

If you're sending a message then you can just send in "say message".

Right now I'm just killing the signal to stop the server, i search for the cuberite detached screen pid and send a kill signal. I supposed there is a better way to stop the server, is a wip so I'm open to suggestions.

Should be able to use
Code:
screen {your stuff} -x exec stop`printf(\\n)`

Unless your screen doesn't support that syntax/I'm outdated (shouldn't be since I checked this a few weeks ago and screen's a fairly stable program), or I'm remembering wrong.
Reply
Thanks given by:
#8
If you have RCON enabled, you could script a RCON client to send the necessary commands to the server. Note, though, that having RCON enabled and open to public is not recommended, because there's no encryption in the protocol - it should be firewalled to allow local-only connections.

Alternatively, it is possible to write a simple plugin for this - listen on a TCP port, verify that the connection is local and if so, execute any command coming in from that connection.
Reply
Thanks given by:
#9
(12-19-2015, 12:06 PM)Zee1234 Wrote:
(12-19-2015, 11:12 AM)Rekuen Wrote:
(12-19-2015, 06:04 AM)bearbin Wrote: How are you stopping the server? Are you piping in a message or sending a kill signal?

If you're sending a message then you can just send in "say message".

Right now I'm just killing the signal to stop the server, i search for the cuberite detached screen pid and send a kill signal. I supposed there is a better way to stop the server, is a wip so I'm open to suggestions.

Should be able to use
Code:
screen {your stuff} -x exec stop`printf(\\n)`

Unless your screen doesn't support that syntax/I'm outdated (shouldn't be since I checked this a few weeks ago and screen's a fairly stable program), or I'm remembering wrong.

Thanks, it wasn't exactly like that but I got it working, the only thing left is to know what files to preserve, or not to override from the tar in every update.

So far this is what I got:

Debian based service/daemon:

service cuberite start -> check for updates and starts the server
service cuberite stop -> stops the server instantly, without warning the users.
service cuberite restart -> stops the server instantly, updates the server, and launch it again.

service cuberite update -> Sends a warning message to the users online through chat, that the server is going down for maintenance in 5 minutes. Every minute sends another message. Once the 5 minutes has passed it stops the server, check for updates, and relaunchs the server.


Restart and update, is the same thing, but one is for development/testng servers so to speak, and the other for production servers with players in it.

The other part are the cronjobs, as said before, one checks every X minutes that the server is online, if not, checks for updates, and starts the server again.

The other cronjob is the one that executes the update command of the service at the time of your preference, every day, at 06:00 AM for example.

Combining the two, cron and service one could forget about being constantly monitoring the server.


TODO: make an install script, that checks dependencies like screen, installs them, copy the service to init.d and update update-rc.d and asks you some questions to set up the cronjobs.

If people is interested I can adapt it to fedora or other distributions, and I'm open to suggestions, once I have it polished i will publish it on github.

Thanks again and sorry for my English.
Reply
Thanks given by:
#10
If you're designing it for debian, why not just go the whole way and make a .deb package?
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)