 The next talk is, let me unlock my phone first, is from Stefano Frantelo and it's PBX on a non-specialized distro. So, yeah. Give her applause. No. Okay. Hi to everyone. I'm Stefano and I'm a server developer. I'm here to talk to you about how and why we package the PBX inside NetServer. NetServer is a multipurpose distribution and the issue that we encountered when packaging it. First of all, the software we choose for the PBX was Hustry's Canfree PBX. They are both quite old but they fit very well in the environment that is in our user case. And Hustry's is very flexible and it fit well in an enterprise environment starting from small enterprises to the big carrier and providers. And that's why probably the main, a lot of choice that you do when you build Hustry's is about that and that's why its main distribution method is the source code. It's hard to find the updated packages of Hustry's. Free PBX is the web interface for Hustry's. It's a PHP web interface and it has a MySQL database or a SQLite database in some case but it's not 100% support so we choose to use Maria. And when you configure Free PBX it stores its configuration into the database and when you apply configuration it writes Hustry's configuration file then reload them. It's written in PHP, it's modular, it's also very extendable and it's easy to write your own modules. Okay, when we choose to package the PBX we start taking a look from the CIS admin point of view on why CIS admin should choose to have the PBX on a multipurpose distros instead of having a specialised one. There are a few specialised distros and the pro of having a specialised distro are that they of course are easy to install and they are cutting edge, they always have the last updates from Hustry's and Free PBX modules. They have commercial modules and this can be very important because also you have paid support. In the case of the Sangoma distros they give paid support only if you have your distros and because of this usually are installed in an enterprise environment. Usually having paid support available is mandatory. The cons of having a specialised distro is that sometimes they are bleeding edge you can't always trust the updates and you can't use your server for something else too. Sometimes in an enterprise environment it can be useful to have more application on the same server to reduce the hardware to maintain and to monitor. You have to do manual configuration when you use this kind of distros for everything and maybe your distro as a nice guy with user friendly interface but in this case you have to manually configure everything that is not configured inside the Free PBX. But you can't manually configure everything if you want because some Free PBX modules write their configuration and mess with your configuration. Now a distribution point of view. The reasons why we choose to package PBX is that first of all having more user. Having more user is part of this virtual circle that helps to make a better distro. Second, we wanted to provide the PBX for our current user and as enterprise to our customers. And also it's important for us to have the PBX on a multiple purpose server for the reason I said before. And it's also easier as enterprise to give support because when you have a support team you have to train the team only on another application instead of a whole new system. There are also the reasons that depends mainly on why you are building a distribution but I think that we can summarize that there is still a big interest in this kind of application in the enterprise environment. The distro I'm talking about is NetServer. I don't know if you already hear it. Who know NetServer? Who already know NetServer? NetServer is a CentOS-based distribution and unlike other CentOS-based distribution it doesn't rebuild the packages from CentOS but add a layer over those packages to help the configuration. And this layer of configuration has another layer that is a web guy that help the admin to have a user-friendly interface to configure everything. That's an overview of the NetServer architecture but it's quite complex and I'm not going to talk about it today. If you are interested there are a lot of documentation on the internet. Okay, let's now see what are the issues that you encounter when you try to package those applications and also the issues that you encounter when you try to package similar applications. Okay, first of all, FreePBX requires HTTPD to run as Asterisk user and this is quite simple to solve. The problem is that we need to have two instance of HTTPD because we don't want the normal instance of HTTPD to run as Asterisk user. So we create another instance by creating another configuration and creating another system D or whatever service that use this configuration. The second problem here is the PHP version. We use the upstream CentOS FreePBX PHP version. In our case it's CentOS 7 and it's 5.4. FreePBX 14 needs 5.6 but we don't want to install for everyone the 5.6 because it can brokoder application. So we installed PHP from SGL and since we already use another HTTPD instance we configured this instance to use PHPFPM from the newer version of PHP. This has a drawback. That means that the two version of PHP runs at the same time in the system. This has the drawback that is when you want to run a shell command that use the newer version of PHP maybe for using the FreePBX console you need to load before the environment. But there is also an advantage that is very easy for us to migrate to another version of PHP when it's required. It will be very easy for us to migrate to PHP 7 because only FreePBX in the system will use this version of PHP. Another issue that we encountered is that it's not easy to find the updated package for Asterisk, FreePBX and their dependencies. So when you start to build a new package you can't find, it's not easy for you to find other packages to copy from. We were lucky here because we can take SangomaSource RAPM is a very good starting point because they are very up to date. It's not very easy to take them because the repositories aren't browsable. But if you want to start now to do this, you will probably take a look to our GitHub where we have all our source RAPM and we are ready to do the best that we can from other packages. Okay, that's the worst part. Pics like many other applications use an installation script for putting file around, change permission, and configure database, start and stop service. And this is very bad because you can't use a normal RAPM to put file around and to check permissions. The solution, we don't have a solution here because you have two options. The option one is to take the installation script and use it inside your package, but it's ugly because you are using an installation script that fails, you don't have GPG check and integrity check and everything. The other option is to let the RAPM do the right thing and put file in the right places, but we choose the one because the second was too time-consuming and it took us too far from the vanilla FreePBX and would be hard to keep peace with update. Basically, it could mean to fork and we didn't want to. Okay, another issue is how to take care of backup. NetServer has some backup and FreePBX also has backup models, but we didn't want to use it because we don't want to configure another backup on the model when we have already configured the system-wide one. So we take all the databases and when we want to restore it, we just install FreePBX as a new installation, and throw away is database and install the backup one. Okay, another issue is that Hasterisk has a few kernel models that are used for timing and for internal hardware. And when you use those models, if there is a kernel update that doesn't depend on you, but in our case, we use upstream kernel so we can't know when a kernel will be updated. Substantially, the update is broken if you don't rebuild the kernel models. The solution here we adopted was to use week updates that is a nice feature of CentOS that allow you to install the kernel models in another kernel with the same major version. It's not the same solution that FreePBX used in their distro because they build the kernel too. If you are building the kernel or if you use, I don't know, maybe some Jenkins, you probably would like to build the kernel models every time. Okay, FreePBX has the capability, a model to configure the WebRTC extension, but they are still also quite difficult to use. So we added Janus Gateway that is WebRTC to CIP Gateway. It's a very cool software and if you are interested, there is a talk about it tomorrow in the real-time track. And that's all. If you want to talk about NetServer, there is a development room in this building at 16 p.m. And if you want to contact me for talking about PbX or whatever, just use my contact, I will be very glad to hear from you. Thank you. Thank you, Stefano. Does anyone have any questions for him? We still have one more minute left. Question? I guess just one comment. Mostly, Daddy, it still breaks on every major release of CentOS on every point release, but you mostly don't need it. For timing, you really don't need it on recent asterisk unless you use MeetMe instead of Contrary. Okay, yes, you're right. Daddy is not mandatory for timing. You also have a better option. In my experience, they don't always work well when you need very strict timing like for fax. So, yeah, I think that's it. A round of applause. Thank you.