Packaging effort

19 views
Skip to first unread message

Mikael Fridh

unread,
Jul 27, 2011, 11:42:51 AM7/27/11
to xtrabac...@googlegroups.com
Back in June I made an RPM of XBM. Obviously, alot has happened since and due to lack of time and committment I haven't revisited it again in a while.

Anyway, thought I'd show you the old patch so you get a view of my ideas and perhaps get a feel for whether or not you'd like me to revisit it against the current code base.

The idea is, allow xbm to be installed in the system in a more package conventional way, and if there's an /etc/xbm/site.php, use it. otherwise default to "current directory" defaults.

The simple framework and resulting spec file can be found at the url below, minus some perl helper functions I use.

http://code.tmtowtdi.se/tmp/mysql-xtrabackup-manager/

mysql-xtrabackup-manager.spec
xbm-0.1-20110609svn-rpm.patch

Lachlan Mulcahy

unread,
Jul 28, 2011, 2:37:46 PM7/28/11
to xtrabac...@googlegroups.com
Hey Mikael,

I really like where this patch is going!!

I'm wondering if you're going to be visiting the SF Marin office sometime shortly after you start with us or not?

If not, maybe we can set aside a time to have a quick chat.

I like the idea of making the project more of a "clean" and standardised install style.

You also provided me with a good reason to consider keeping the basic configuration of XBM itself in a file as opposed to the DB.

I'm now working on some design for the configuration/mangement command-line interface (setting up hosts, backups, restoring, etc) and I was considering pushing these options into the DB, but for now i think I will leave it more file based.

I may even move the configuration file away from a PHP code file into something like an XML configuration file so that the user/administrator's configuration work is separated away from the code itself.

Lachlan

> <mysql-xtrabackup-manager.spec><xbm-0.1-20110609svn-rpm.patch>

Mikael Fridh

unread,
Jul 29, 2011, 4:51:06 AM7/29/11
to xtrabac...@googlegroups.com
On Thu, Jul 28, 2011 at 8:37 PM, Lachlan Mulcahy
<lachlan...@gmail.com> wrote:
> Hey Mikael,
>
> I really like where this patch is going!!
>
> I'm wondering if you're going to be visiting the SF Marin office sometime shortly after you start with us or not?

I'm hoping I will. I'm leaving my current job end of next week to
spend my vacation days, I'll try to sort out some details then.

> If not, maybe we can set aside a time to have a quick chat.

Definately. I'd have to take a look at your newly committed code
first. Probably will have time if there are any rainy days in August
:).

> I like the idea of making the project more of a "clean" and standardised install style.

Plus, it allows for a system install (yum install
mysql-xtrabackup-mgr) and then any user on the server can run it. Not
necessarily the 'xbm' user which was sort of required in the version
you had there back in June. The 'xbm' user and 'xbm' group would
probably only make sense if there was an xbm daemon mode in the future
in this kind of idea. I guess there are two routes to take... a backup
tool any user can run, or a daemonized backup tool run by the server
administrator. Perhaps both...

--
Mikael

Lachlan Mulcahy

unread,
Aug 3, 2011, 12:44:14 PM8/3/11
to xtrabac...@googlegroups.com
Hi Mikael,

My replies inline,…

On 29/07/2011, at 1:51 AM, Mikael Fridh wrote:

> On Thu, Jul 28, 2011 at 8:37 PM, Lachlan Mulcahy
> <lachlan...@gmail.com> wrote:
>> Hey Mikael,
>>
>> I really like where this patch is going!!
>>
>> I'm wondering if you're going to be visiting the SF Marin office sometime shortly after you start with us or not?
>
> I'm hoping I will. I'm leaving my current job end of next week to
> spend my vacation days, I'll try to sort out some details then.

Sounds good.

>> If not, maybe we can set aside a time to have a quick chat.
>
> Definately. I'd have to take a look at your newly committed code
> first. Probably will have time if there are any rainy days in August
> :).

Great - I want to do some clean up in there before I proceed with the config interface step. Some of the code there has come together sort of organically as I decided the different features I wanted "on the fly" as opposed to the ideal of spec/design/implement (story of every developers life perhaps).. It also could do with some better comments :)

That should help you and others in understanding what the heck is going on in there a little more :)

>> I like the idea of making the project more of a "clean" and standardised install style.
>
> Plus, it allows for a system install (yum install
> mysql-xtrabackup-mgr) and then any user on the server can run it. Not
> necessarily the 'xbm' user which was sort of required in the version
> you had there back in June. The 'xbm' user and 'xbm' group would
> probably only make sense if there was an xbm daemon mode in the future
> in this kind of idea. I guess there are two routes to take... a backup
> tool any user can run, or a daemonized backup tool run by the server

> administrator. Perhaps both…

The catch with having it not install under the xbm user is that the way that the scheduled backups are launched right now is by taking over a specified user's crontab completely.

I'm not sure how I'd go about utilising cron, without having that ability.

In addition, SSH key trust needs to be setup between your xbm user and your remote hosts in order to facilitate xbm logging in via SSH and running the backups as needed. You'd need to setup SSH key trust for all users on your system that wanted to run xbm otherwise..

Maybe you have some good ideas about how I could modify the way some of that works to be more flexible towards system install, etc.

There might be some other things that I forgot, but those two are the first that come to my mind.

Meanwhile - enjoy your time off between jobs! I hope it is not too rainy!

Lachlan

Henrik Ingo

unread,
Aug 4, 2011, 3:06:47 AM8/4/11
to xtrabac...@googlegroups.com
On Wed, Aug 3, 2011 at 7:44 PM, Lachlan Mulcahy
<lachlan...@gmail.com> wrote:
> The catch with having it not install under the xbm user is that the way that the scheduled backups are launched right now is by taking over a specified user's crontab completely.
>
> I'm not sure how I'd go about utilising cron, without having that ability.
>
> In addition, SSH key trust needs to be setup between your xbm user and your remote hosts in order to facilitate xbm logging in via SSH and running the backups as needed. You'd need to setup SSH key trust for all users on your system that wanted to run xbm otherwise..
>

For ssh and scp, you can give the key as a command line parameter if
it's stored somewhere else than the user's .ssh/ directory. So you
could have the key file just stored somewhere, and the location would
be stored in the xbm config database, then used on all calls to ssh.

For crontab, I don't know how to do it without having your own user.
(Excluding solutions equivalent to writing your own cron.)

Personally, I don't think it is wrong to have a dedicated xbm user. It
is common for unix services to run under their own user account, and
xbm falls into that category. (Even if it is not running as a daemon
but only on scheduled events.)

What should be done however would be to clean up the installation
procedure a bit, so that you don't have a real user with /home/xbm and
everything, but rather a system user that doesn't show up in your
login dialog, and has home directory set to something like
/usr/lib/xbm or /var/lib/xbm (I'm unsure about the Linux Standard Base
here, just see what others are doing).

But even such cleanup is to me icing on the cake, functionally it's
pretty similar to having a /home/xbm.

henrik

--
henri...@avoinelama.fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc

My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559

Lachlan Mulcahy

unread,
Aug 4, 2011, 2:36:22 PM8/4/11
to xtrabac...@googlegroups.com
Hey Henrik,

> For ssh and scp, you can give the key as a command line parameter if
> it's stored somewhere else than the user's .ssh/ directory. So you
> could have the key file just stored somewhere, and the location would
> be stored in the xbm config database, then used on all calls to ssh.

True. This could be done fairly easily.

> For crontab, I don't know how to do it without having your own user.
> (Excluding solutions equivalent to writing your own cron.)
>
> Personally, I don't think it is wrong to have a dedicated xbm user. It
> is common for unix services to run under their own user account, and
> xbm falls into that category. (Even if it is not running as a daemon
> but only on scheduled events.)
>
> What should be done however would be to clean up the installation
> procedure a bit, so that you don't have a real user with /home/xbm and
> everything, but rather a system user that doesn't show up in your
> login dialog, and has home directory set to something like
> /usr/lib/xbm or /var/lib/xbm (I'm unsure about the Linux Standard Base
> here, just see what others are doing).
>
> But even such cleanup is to me icing on the cake, functionally it's
> pretty similar to having a /home/xbm.

I agree on pretty much all of the above..

I'm hoping I'll get some time to sink into XBM quite soon.. so stay tuned!

L

Reply all
Reply to author
Forward
0 new messages