Click to close the image preview
Hi folks, I just grabbed mozybackup_pro_1.0.6-4505_i386.rpm and noted the filename change there. The previous version had a filename of mozybackup_1.0.4-4501_i386.rpm. I was cautious in upgrading, due to what looked like a package name difference here (using the RPM definition of package name) but the upgrade went smoothly. So that's confusing.
The filename uses "mozybackup_pro" but the package name is still "mozybackup":
# rpm -qip mozybackup_pro_1.0.6-4505_i386.rpm | grep Name
Name : mozybackup Relocations: (not relocatable)
Was the intent to rename the package to mozybackup_pro? In the RHEL/RPM world, the filename should match the package name. That's generally set in the spec file when building the package, like so:
Solved! Go to Solution.
Thank you @TummySupport2 - Mike,
Great question! We are making the change from mozybackup to mozybackup_pro to take advantage of upgrade abilities found in the Admin Console.
With that said, we are currently investigating any impact and discussing this with our Linux engineering teams. I will continue to keep you and this post updated.
I agree that the rename of the installation file means that it doesn't match the internal package. We have intentionally kept the package name as mozybackup and will probably stick to that, but now are producing several different installations to match the different types of accounts we have.
Technically the different builds only change the default for the mozy.codename variable, which is used for activation and upgrade. This is visible in the mozybackup.conf file. Other than that they are exactly the same software. We have considered adjusting things so that the "pro" and "enterprise" builds contain completely distinct package names. But unless we also renamed all the executables and data directories to be distinct those packages would actually conflict with each other. In other words it wouldn't be possible to install both side by side. So until there is some clear advantage to our users I am hoping we can keep things with a single "mozybackup" package with the small extra detail of needing to know which one to install.
BTW I expect the naming convention on the installation packages will change again to match the convention used by the other Mozy products. Unfortunately its hard to keep things consistent across cross-platform Mozy products as well as perfectly matching platform specific standards like the RPM naming. Hopefully we can find the right balance between the two and avoid any unnecessary confusion!
I can see the reasoning behind that, but I would still recommend trying to avoid it. Another small extra detail would be that from someone to change from the basic package to the 'pro' package, they might need to get tricky with the package, especially if the verison numbers are the same.
For example, if I have "mozybackup_pro_1.0.6-4505" installed and I need to install "mozybackup_enterprise_1.0.6-4505", I would need to first remove mozybackup_pro then install mozybackup_enterprise followed up with replacing /etc/mozybackup.conf with the newer /etc/mozybackup.conf.rpmsave that the new package installed, copying any of my customizations over to the new conf file. Because the package name is still 'mozybackup', a normal rpm install/upgrade wouldn't work without a --force. Similarly on the Debian/Ubuntu side, replacing an alread-installed pacakge would require a special set of options as well as prompting for what to do with /etc/mozybackup.conf if it has any customizations within.
Programatically, one thing that many packagers are using now is a directory in which local customizations can be made that aren't affected by package changes. I refer to these as ".d" directories as they are generally named with ".d" as a suffix. for example, yum itself uses /etc/yum.repos.d/ and within this directory I can add repo definition files that upgrades of the yum package do not affect.
Using the above, you could create an empty directory as part of your base package named "/etc/mozybackup.conf.d/" or the like, make sure that the mozy-daemon itself or /etc/mozybackup.conf can include maybe *.conf from within that directory. If mozy-daemon is then reading in configuration file(s) and settings in a "last read is used" type of operation, anything within this directory will override the defaults in /etc/mozybackup.conf. You could put things like custom excludes, account info, server info, etc in these *.conf files.
With such a setup, you'd really only need the base mozybackup_1.0.6-4505 package and pro/enterprise/etc changes could be handled with something as simple as:
echo "mozy.account-type = pro" >/etc/mozybackup.conf.d/account.conf
That's a bit of an over-simplification, but from a sysadmin perspective, where we're updating hundreds of systems in an automated fashion, we don't want to have any exceptions to handle when we're rolling out package updates.
On a side note, if you setup these packages for use from a repository (which would be a plus!), keeping the filenaming and package names identical is a good idea and, I think, required. At least if you want to avoid yet another little detail to keep in mind when building, packaging, releasing, documenting, etc.
Also, another idea on the packaging front - you could split your packaging up into a base or core package then provide your pro/enterprise/etc pieces as a seperate package. In a repo setup this is nice because then you have your pro/enterprise/etc package *require* the base package and your install instructions would basically be 1) install the repo and 2) install the pro/enterprise package.
Both yum and apt-get will determine required packages and include them for download and installation.
Thanks for all these great suggestions! For example having support for an optional directory for mozybackup.conf override is an very interesting idea, that would certainly give good flexibility - we will look into that. And we will continue to evaluate the best packaging approach.
In the latest update of Mozy Linux 1.0.8, the mozybackup.conf override has been implemented.