[root@pbx log]# service xinetd status
Redirecting to /bin/systemctl status xinetd.service
● xinetd.service - Xinetd A Powerful Replacement For Inetd
Loaded: loaded (/usr/lib/systemd/system/xinetd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-08-14 18:12:57 UTC; 29min ago
Main PID: 718 (xinetd)
CGroup: /system.slice/xinetd.service
└─718 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing discard
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing echo
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing echo
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing tcpmux
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing tftp
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing time
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing time
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: xinetd Version 2.3.15 started with libwrap loadavg labeled-networking options compiled in.
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: Started working: 0 available services
Aug 14 18:12:57 pbx.axcoadhesive.local systemd[1]: Started Xinetd A Powerful Replacement For Inetd.
While I cannot answer your actual question I would suggest that you try out HTTP provisioning sometime as it works much smoother than TFTP and I’ve had less problems with it.
TFTP doesn’t run all the time, but you should be able to enable it by updating the tftpd file in /etc/xinetd.d. Remember that the option is backwards )“disable = false” turns it on). Once you have that, xinetd will manage your TFTP sessions.
Not in my experience. It’s always run out of xinetd (and inetd before that). In fact, that’s the primary reason for having xinetd installed. I’ve never seen a Unix-like system where TFTP ran all of the time. Of course, I could be wrong, I’ve only been doing this kind of work since the 1980s.
Well I don’t know as much as you, but how are phones supposed to provision via TFTP if they can’t receive the configs as the service isn’t running? Or am I missing something?
Xinetd starts an instance of TFTP for every request, thereby preventing a single instance from locking everyone else out. This is a more appropriate use of resources than trying to have one, and only one, TFTP running trying to respond to phone config (or other file transfer) requests.
IIRC, Commercial EPM resets the xinetd TFTP server to start on demand. If it isn’t, I think it’s a bug. We (the list) talked about this a couple of months ago and I recall that being the way forward.
Having TFTP enabled “be default” is not an industry best practice. We normally want the server disabled and turn it on “on purpose”, which is why I suggested updating the /etc/xinetd.d/TFTP file to “enable” the TFTP service so that you can get the software downloads working.
So we should not be using TFTP to provision phones any more? Re: “The way forward”
This is what I know:
Reboot server
Default a phone
It can’t get a config via TFTP unless I start the service.
^^^^ This is normal behavior now
As a FreePBX user myself I expect it to just “work”… but maybe again I’m missing something in the change from 13 to 14 in terms of TFTP provisioning not being the way to go.
EDIT: I want to do it the “right” way, so please let me know what that is now.
No, we should not be turning the TFTP service on by default.
Setting the service up to work is perfectly reasonable and is a well-understood and necessary way to configure certain phones. Some phone manufacturers (Polycom comes to mind) prefer their customers use FTP or HTTP. IIRC, Sangoma prefers HTTP. Other manufacturers have other preferences, so the phone you are using will determine which protocol you are going to have to use.
The more I think about it, it might have been a Firewall thing instead of an EPM thing. Rob @xrobau would probably remember better since he’s one of the firewall gurus.
If you’re using TFTP, you are likely to be working by hand in the TFTPBOOT directory (EPM notwithstanding). Setting up the files needed in the TFTP directory isn’t always drag-and-drop and sometimes requires access through the CLI.
The TFTP service should be starting under xinetd. That’s why the config file for the service is in the /etc/xinetd.d/ directory. For whatever reason, your TFTP is disabled. Enable it (I think I’ve told you how twice now) and move on.
For security reasons we do not have TFTP start on boot as its very insecure. In sysadmin module in the PBX you can tell it to start under provionsing protocols.
Although the wiki does still state:
Define what Provision Server Protocol you want to use to have your phones receive their config files: TFTP should be used when phones are local to the PBX, as it’s easy to use and requires no setup.
We bought all Sangoma equipment and don’t really have a need for the commercial sysadmin module. I suppose I have to buy it to turn TFTP on, or do it manually? Or look to other provisioning protocols?
Can you open a feature request to have us enable tftp by default on new installs and we can evaluate as we use to do that but in SNG7 that is not the detault
(Find the line that reads “disable = yes” and change it to “disable = no”)
:wq
systemctl restart xinetd.service
Not sure why it’s in tftp.rpmnew instead of just tftp; both files are there, but one was enabled and the other wasn’t. Whatever. They’re both enabled now, and it’s working again.
IMNSHO, if tftp is going to be disabled by default, then enabling it via the sysadmin GUI should not require the commercial version. Many phones don’t support http for various things (not only provisioning, but custom backgrounds, ringtones, etc.).
If a file was installed as part of a rpm, it is a noreplace-config file (i.e. marked with the %config(noreplace) tag), you’ve edited the file afterwards and you now update the rpm then your old config file will stay in place (i.e. stay active) and the new config file (from the newer rpm) will be copied to disk with the .rpmnew suffix.
Well, the “tftp” file that didn’t get replaced was also not respected by the upgraded system, because it already said “disable = no” but tftp was most certainly not working until I made the edit to the tftp.rpmnew file. So maybe this is a bug in the FreeBSD SVN7 distro.
I deleted the tftp.rpmnew file (after determining that its contents were identical to the tftp file), restarted xinetd again, and it’s still working. So apparently all I really needed to do post-upgrade was delete the “rpmnew” file.