Req: More friendly for shared hosting

  • Wolfie

    Wolfie - 2011-10-07

    I'm on shared hosting (I'm poor) and I have some ideas that would be really great for making it more friendly for those who are on shared hosting and not exactly brilliant with customizing this to work properly on it.

    1. If a conf file isn't specified, have it check the current folders (executed from as well as where the script is actually located), then branch out to other locations.

    So it would work in this order, presuming that I'm in (and run the script from) /home/user/website1/scripts/ and the AMSB (AutoMySQLBackup) is in /home/user/scripts/

    - It would look in /home/user/website1/scripts/ for a conf file
    - Next in /home/user/scripts/
    - Other locations as it already does

    This would make it possible to have a cronjob run a script that's for one site and use on conf file, then a different cronjob that would run the script from a different location.  I know that it the paths to the different conf files could be specified, but for ease of use or if someone moves from one hosting to another, it could be a blessing to have it check more locations.

    2. Make it possible to specify a 'profile' conf name.  Similar to what it does now, but in conjunction with the above idea.  When it checks the different locations, have it look for <name>.conf, so if I use -profile website1, it would look for website1.conf is the different folders.  Would make it convenient if different 'profiles' could be stored in the same folder as the script and only have to specify the profile to use and have it use that one.

    3. Still learning about it so if this is already possible (so far doesn't look to be), be able to run commands/scripts before and after the actual SQL backup is performed.

    4. Move the internal configuration options near the top of the script, so if someone feels that they *must* change them, it's easier for them to find instead of digging down deep, which in turn increases the changes of fubar'ing something.

    5. Perhaps have it look at the name used to call the script, so that if a specific name is used (or a certain word in the name is used), then it might bypass checking different locations and instead rely solely on the internal options or at the very least, bypass the 'root' folders.  Would be good for shared hosting, if renaming it to something like automysqlbackupshared would cause it to limit the areas it tries to explore.

    If nothing else, a dummy's guide for how to set it up to run on shared hosting would be greatly appreciated.

  • PittaGurneyi

    PittaGurneyi - 2011-10-07


    please let me give you reasons as to why not all of these ideas seem good to me.

    1. It is a serious security risk to have the script search folders for config files. Think of it as giving somebody the possibility to just put some file in the right path and put their own commands in there, which will most likely be run by cron, which runs as root. The config files are source'd, which means that everything in there is just executed in the current script environment. Of course if the right permissions are set for all possible folders or parent folders and no error is made concerning these permissions, this wouldn't be a problem. But creating such security risks isn't exactly smart. Assuming that /etc is properly protected, the standard config file /etc/automysqlbackup/automysqlbackup.conf is included, which can in normal circumstances be assumed safe. Putting config files in the directory where the script is, would probably be some bin folder, where they most certainly don't belong. Depending on how cron runs the script, the current working directory (one of your proposed search folders) doesn't have to be the directory in which the script itself is located. I honestly don't even know which folder that would be on my system … would have to test that.
    So for the more common case of a system to which you have full access, this folder searching thing is as far as I'm concerned not a good idea. Please read on for an idea how to at least in parts realize what you want.

    2. If you specify the profile, you can just type in five more characters, namely .conf or even omit the ending of the filename, which doesn't matter at all - naturally only if the filename has no ending. The script doesn't care which filename is supplied as long as it is a file. So in principle, if you do something like "cd /home/user/website1/scripts && automysqlbackup profile1" it would change the working directory to /home/user/website1/scripts and on success execute automysqlbackup with the parameter profile1, which is the filename in the current working directory - just what you wanted. This way you only have to change the cd command and can move the script to wherever you want. So from my point of view it is just fine the way it works.

    3. There are pre- and postbackup scripts, which are executed before and after the backup, respectively. Just specify scripts in your config file.

    4. For the sole purpose of removing the need to edit the script at all, I have created the possibility of the global config file. Still I'm going to do you the favor of moving this part to the top. In the next version it will be right at the top in the load_default_config() function. Just change what you want there but please don't change anything outside the {} unless you know what you are doing.

    5. Problematic. Let's leave it at that.

    Concerning the guide for setup on shared hosting, I can't help you, because I have no such hosting. Perhaps somebody else could help. Of course the install script isn't written for such a case, but since I have no interest in changing anything aside from moving code from one place to another and fixing important bugs, I won't do feature requests for many months - nearly completely rewriting the script took much longer than anticipated and I have no time to work on the script right now.

    I hope I could help.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks