Hi everyone,
I’m a NethServer (NS) developer (CentOS 7 based and 100% compatible distribution) and I’m trying to have FreePBX
14 packaged for NS. I took a look to freepbx 14 rpm and I noticed that it has some strange behaviours:
· some directories and files are created during %post
· there are a lot of chmod/chown in %post
· sed of php.ini
Then the installation script is launched and it copies some files, creates symlinks, and do a few others chmod.
Consequences are that:
· rpm -ql freepbx doesn’t list real freepbx files but those under /usr/src/…
· rpm -V doesn’t show changed files. I could mess with /var/www/html/admin/ files and rpm -V keeps giving me freepbx package as intact
· rpm -V of asterisk* packages says that some files and directories has changed ownership and permission (and updating or reinstalling those packages change back those permissions)
My questions are: why rpm install freepbx like this? Wouldn’t be better to install freepbx during rpm %build instead of %post? How do you handle Asterisk upgrades if upgrading Asterisk packages change back file permissions?
Right, modules would remain untracked (unless modules are rpm too, that woud
be awesome ), but at least you’d have core files tracked.
[quote=“tm1000, post:2, topic:36031”]Changing or reverting the freepbx project using an RPM is dangerous and can
actually break your system. This is why we don’t do that[/quote]
If you talk about the risk of having a database version newer than module version, I get it, yum downgrade could break your system (but upgrading again would fix it). rpm itself isn’t dangerous, it’s used in production by biggest companies for A LOT of software, maybe it’s dangerous to use this hybrid kind of packaging and installation (rpm + shell script + php script), because you change files outside rpm system and if an update change back those files you’ll have different permissions.
I think using rpm like this is like using tar + scripts, that once was good, but rpm is more powerful than that.
But you wouldn’t have core files tracked. Those files can also change. I see what you are getting at it’s just that the RPM would never have the right file count. So then I have to ask. What’s the point?
Remember FreePBX itself is a GUI for asterisk and is installed on lots of Distros so FreePBX itself has to be agnostic. So FreePBX and the installer is designed to be gone from a tarball. For our Distro we build a simple wrapper RPM to get FreePBX installed but FreePBX is 100% designed to be modular including the Core and upgrades can only be done through module admin as each module handles all migration and changes and checks for other modules. Do not try and use RPMs to upgrade FreePBX. You will always be breaking things. Use our fwconsole module system.
Hi all!
I understand what tonyclewis and tm1000 say but as FreePBX runs in a distribution you cannot ignore the system layer… Yes, i know that it works but you know how it is difficult to mantain a software that overwrite itself without a packaging system… this is why rpm exists… so i think you should implement a package layer and each time FreePBX wants to update itself or some modules it should download a package… this mean that you should choose a default distribution for it.
Yes that is the reason for module admin. Its a package system. Just like Node JS now has its own package system. You can not use RPMs for this and have to use the FreePBX module admin system. This system has lots of smarts and dependancies into it and ability to revert back to previous module versions. FreePBX as a whole is not a single application. Just like wordpress or drupal when you want to update those you do them from their update system not through some RPMS update because again they are modular systems like FreePBX.
If you are going to try RPMs to update you are not going to have much success and always be breaking things and having to change the core of how FreePBX handles things.
Everything you can do from the module admin GUI in FreePBX can be done through fwconsole commands.
Only if you allow to update core module outside RPM, if you keep RPM updated there’s no need for it.
The point is that you’d have a system easier to maintain, easier to manage, easier to fix and more secure.
I agree that from a FreePBX developer point of view it should be agnostic, but this doesn’t mean to force packagers to wrap tarball and scripts. You can produce a tarball and an install script, the problem is when you build an update system for FreePBX itself and all it’s modules inside FreePBX.
And the problem isn’t modularity itself, the problem is making an infrastructure that allow PBX administrator to install, remove and update modules even if he isn’t root. Like if FreePBX was a kind of CMS. But managing a PBX involves too much of the underlying system to be managed as a CMS.
No more
# dnf search nodejs | wc -l
1230
I know, but I’d like to have a good RPM without breaking core, that’s the point of this discussion
We (me and my team) have a good experience of making RPMs and a bit on FreePBX, we’d like to collaborate with you to have a good rocksolid RPM that we can use on our system and on yours.
We could make a FreePBX RPM for NethServer without you, crippling FreePBX module system, but if we go in different directions I’ll have to work a lot to deliver an outdated RPM. If we rather work together, we can both have advantages (and I bet that .deb guys would be happy too)
Ok well you can do what you want but its not how we handle our Distro and FreePBX is all designed around its module system and module admin to handle all of its packages and updates and not something we will be spending time on with everything else we have to do still to deliver features to customers they are asking for and this would just complicate how FreePBX works already with its own module system.
Tony means nodejs modules. Your statement is irrelevant because you are talking about nodejs itself. Not the modules you’d add from npm -g
Unfortunately we don’t have time to focus on this. It would be a huge undertaking. As Tony said you are welcome to do it yourself. The source code is avaliable online. You’d have to figure out how to disable the freepbx module system. And then in 14 you’d have to disable automatic security updates which in itself would be terrible.
), but at least you’d have core files tracked.