Rocky 8.9 - Tried the script.

[cjemorton]

I tried the script as suggested here:

https://github.com/asterisk/dahdi-tools/issues/9#issuecomment-1925731319

It seems it was written for a Debian specific environment (apt-get, not yum & or dnf) Also, it seems it doesn't like that I am on an older kernel - (I need an older kernel because of the hardware - newer kernels drop support for my,

Intel(R) Atom(TM) CPU D525

which is the hardware I have available currently (yes I know its old)

root@rocky /u/l/src [SIGINT]# phreaknet install --force --dahdi
Real time pusling is not compatible or has been disabled for this build.
WARNING: You are installing Asterisk to run as root. This is not recommended.
Specify -u or --user to specify a run user

Starting installation with country code 1
Installing prerequisites...
/usr/local/sbin/phreaknet: line 583: apt-get: command not found
/usr/local/sbin/phreaknet: line 584: apt-get: command not found
/usr/local/sbin/phreaknet: line 585: apt-get: command not found
/usr/local/sbin/phreaknet: line 587: apt-get: command not found
/usr/local/sbin/phreaknet: line 589: apt-get: command not found
/usr/local/sbin/phreaknet: line 591: apt-get: command not found
/usr/local/sbin/phreaknet: line 596: apt-get: command not found
/usr/local/sbin/phreaknet: line 599: apt-get: command not found
/usr/local/sbin/phreaknet: line 600: apt-get: command not found
/usr/local/sbin/phreaknet: line 1164: apt-get: command not found
/usr/local/sbin/phreaknet: line 1165: apt-get: command not found
/usr/local/sbin/phreaknet: line 1142: apt-get: command not found
Unable to find automatic installation candidate for 4.18.0-513.11.1.el8_9.x86_64 - reboot needed?
/usr/local/sbin/phreaknet: line 1153: apt-get: command not found
Failed to download system headers and exception failed
Your kernel: 4.18.0-513.11.1.el8_9.x86_64
Available headers for your system:
You may need to upgrade your kernel using apt-get dist-upgrade to install the build headers for your system.
Installed:
total 12
drwxr-xr-x.  5 root root  106 Jan 28 00:48 .
dr-xr-xr-x. 36 root root 4096 Feb  4 23:55 ..
drwxr-xr-x.  7 root root 4096 Feb  4 05:22 4.18.0-513.11.1.el8_9.x86_64
drwxr-xr-x.  6 root root 4096 Jan 27 23:53 4.18.0-513.5.1.el8_9.x86_64
drwxr-xr-x.  3 root root   19 Jan 27 23:38 4.18.0-513.el8.x86_64

[InterLinked1]

It seems it was written for a Debian specific environment (apt-get, not yum & or dnf)

Yes, it's primarily Debian-centric since that's what I and most PhreakScript users use - not to say that's intentional, just a byproduct of development and usage drivers.

There is some support for Fedora based distros (with yum/dnf), although it's not as robust.

Do you mind sharing the output of phreaknet info so we can look into this more? For instance, it seems to be autodetecting your system as apt based, which is wrong.

[cjemorton]

Sure. As my previous post on the other thread: https://github.com/asterisk/dahdi-tools/issues/9#issuecomment-1926267390 That's my system, and I was able to get dahdi-linux to install using those procedures, but it would be better if we could get this script working properly.

` root@rocky /u/l/src# phreaknet info Hostname: rocky Rocky Linux release 8.9 (Green Obsidian) Linux rocky 4.18.0-513.11.1.el8_9.x86_64 #1 SMP Wed Jan 10 22:58:54 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux Package Manager: apt-get gcc version 8.5.0 20210514 (Red Hat 8.5.0-20) (GCC) Asterisk 21.1.0 DAHDI Tools Version - 3.3.0 DAHDI Version: PhreakScript 1.1.1 (2024-01-12) https://github.com/InterLinked1/phreakscript (C) 2021-2023 PhreakNet - https://portal.phreaknet.org https://docs.phreaknet.org To report bugs or request feature additions, please report at https://issues.interlinked.us (also see https://docs.phreaknet.org/#contributions) and/or post to the PhreakNet mailing list: https://groups.io/g/phreaknet

`

[cjemorton]

Also, of concern and note is that the DAHDI version is not being detected. Which tells me something isn't installed correctly or something isn't detecting it.

root@rocky /u/l/src# dahdi_hardware pci:0000:02:08.0 wctdm24xxp+ d161:8006 Wildcard AEX410P

root@rocky /u/l/src# dahdi_scan [1] active=yes alarms=OK description=Wildcard AEX410 name=WCTDM/0 manufacturer=Digium devicetype=Wildcard AEX410 location=PCI Express Bus 02 Slot 09 basechan=1 totchans=4 irq=0 type=analog port=1,FXO port=2,FXO port=3,FXS port=4,FXS

[cjemorton]

Potentially a fix something like this, that can detect and set the variable of the shell and package manager to be used.

https://gist.github.com/cjemorton/20a5af1576635d065becfa039836e0ec

[InterLinked1]

Thanks! I'm downloading Rocky Linux 8.9 now so I can test it out a bit.

I'll definitely fix the package manager detection first, although PhreakScript is written for POSIX sh (no bash extensions, for BSD compatibility), so I'll have to add it in a compatible way.

[cjemorton]

Yes! Perfect. I also have a couple systems that run freeBSD so I 100% understand it. I just tossed something together as an example of what I as thinking of logic wise.

I'll test it out when you finish the modification, let me know how I can help further.

[InterLinked1]

I made some preliminary updates (not in Git yet, but phreaknet update will pull them), which fix the package management issue, though I can't seem to get libedit-devel on the system as the package can't be found. Do you have this package by chance, somehow? Seems like that's the right name, it just finds no package by that name, so ./configure fails when running Asterisk.

This is actually included in install_prereq.sh in Asterisk, so it's not something that's been handled in PhreakScript previously, though now I'm wondering if we need to add some kind of Rocky Linux specific workaround. I don't think I encountered that the last time I tested on Fedora though...

[cjemorton]

Yes. Ran into that as well, it's in a development repository, try.

dnf --enablerepo=devel install libedit-devel

Took me awhile to figure this one out, it was a WTF I want my mommy moment for me..

I think development rpms are broken out from base os to lower the amount of package headers or whatever it's called that need to be downloaded on production systems. Makes updates faster.

[cjemorton]

Here is an example run of trying phreaknet.sh phreaknet_20240205_8:37PM

It seems to be choking on that issue of 4 arguments instead of 3 issue.

I don't think there is a patch implemented in phreaknet.sh that addresses that specific issue.

[InterLinked1]

Here is an example run of trying phreaknet.sh phreaknet_20240205_8:37PM

It seems to be choking on that issue of 4 arguments instead of 3 issue.

I don't think there is a patch implemented in phreaknet.sh that addresses that specific issue.

All right, I think both the libedit issue and the kernel API ABI issue should be resolved now, if you're able to give it another shot! I just tested and was able to get DAHDI Linux and DAHDI Tools to compile. If it works for you now, I'll go ahead and commit.

[cjemorton]

I tried to run it, here are the results: phreadnet_20240206_1:30PM

Couple questions.

• Are the SSL Compile errors "normal" behaviour?
• At the end, I have no idea why the patch failed - I don't know which file to provide as a target so, everything just kinda came to a halt.
• Also noticed something funny is going on with the tar command, at line 36 of the output. The whole script hung here for quite awhile before continuing.

[cjemorton]

Out of pure curiosity after posting the last comment. I tweaked the header of phreaknet.sh, adding the -x option to the #!/bin/sh to be #!/bin/sh -x then executed the script again and walked away for an hour for a cup of tea.

When I got back just now, different results. Here are the results of that run. phreaknet_20240206_2:58PM

[InterLinked1]

Out of pure curiosity after posting the last comment. I tweaked the header of phreaknet.sh, adding the -x option to the #!/bin/sh to be #!/bin/sh -x then executed the script again and walked away for an hour for a cup of tea.

When I got back just now, different results. Here are the results of that run. phreaknet_20240206_2:58PM

It looks like your second run went all the way through. Was there an issue?

[cjemorton]

Out of pure curiosity after posting the last comment. I tweaked the header of phreaknet.sh, adding the -x option to the #!/bin/sh to be #!/bin/sh -x then executed the script again and walked away for an hour for a cup of tea. When I got back just now, different results. Here are the results of that run. phreaknet_20240206_2:58PM

It looks like your second run went all the way through. Was there an issue?

I am rebooting now and then going to check see if things are working.

[cjemorton]

I just rebooted and tried to check spans etc. with the dahdi_ commands.

maybe I'm missing something incredibly obvious, but nothing is showing up for me.

https://gist.github.com/cjemorton/814c855850812194476cd0ca999c5098#file-dahdi_

The hardware is being detected as being plugged in, but that's pretty much it.

[InterLinked1]

I'm not sure what's up with that exactly, though I'm inclined to think that's a separate issue from the compilation issues this issue was about - but it'd still be good to figure out why that is.

Did this same configuration (that particular card / kernel version / etc.) used to work? / what has changed since then?

[cjemorton]

Thanks. Yeah, I'm confused as to what's actually going on with it. The same Hardware was used successfully with FreePBX, but I was trying to get away from the absolute mess (IMO) that is FreePBX - all the begging for buying etc. I wiped the system and installed Rocky 8.9 - I was wanting to go with a RPM based distro downstream from Red Hat due to it being supposedly stable. I've had issues with Debian based systems borking themselves after several months running and updates coming out. So I've got a bad taste for anything debian apt-get related if I don't absolutely HAVE to use it. My main servers are running FreeBSD and I've basically been able to roll updates on them for like 3 major releases now without an issue without a full wipe and reinstall. I was hoping to be able to do similar with Rocky. This is a test system, so I can pretty much do whatever I want with it, but I was hoping to be able to create an environment that I could easily manage and update.

The funny thing is, I was able to get the drivers to compile using that other repository. I just went to check on it and get the link, but it looks like something erased everything in my /usr/src/ directory where I had the repository's downloaded. So I will have to go find it and clone them down again. That repository with a few tweaks was able to compile and I was able to see and generate spans with it.

Sorry time is running short for me right this min, I will check back in on this in a few hours.

[InterLinked1]

Thanks. Yeah, I'm confused as to what's actually going on with it. The same Hardware was used successfully with FreePBX, but I was trying to get away from the absolute mess (IMO) that is FreePBX - all the begging for buying etc. I wiped the system and installed Rocky 8.9 - I was wanting to go with a RPM based distro downstream from Red Hat due to it being supposedly stable. I've had issues with Debian based systems borking themselves after several months running and updates coming out. So I've got a bad taste for anything debian apt-get related if I don't absolutely HAVE to use it.

Interesting... I use Debian for all my Linux servers and I've never had that issue. I've found it to be a good choice as a standard Linux distribution, particularly in terms of compatibility.

I can anecdotally say that the vast majority of people I know and service in running Asterisk/DAHDI run a recent version of Debian - not to say that you should too, but it's been relatively issue-free for them and it's more well tested.

My main servers are running FreeBSD and I've basically been able to roll updates on them for like 3 major releases now without an issue without a full wipe and reinstall. I was hoping to be able to do similar with Rocky. This is a test system, so I can pretty much do whatever I want with it, but I was hoping to be able to create an environment that I could easily manage and update.

Yeah, you probably already know this but obviously Asterisk/DAHDI on a BSD system is a no-no.

The funny thing is, I was able to get the drivers to compile using that other repository. I just went to check on it and get the link, but it looks like something erased everything in my /usr/src/ directory where I had the repository's downloaded. So I will have to go find it and clone them down again. That repository with a few tweaks was able to compile and I was able to see and generate spans with it.

You're referring to the osmocom one, right? Yeah, that's definitely a good source and I've discussed this with the guy who runs that. There should be a lot of crossover between PhreakScript and that fork. The main difference is they have a hard fork of the DAHDI repositories whereas PhreakScript involves no forks - it's all patches on top of the latest supported releases. It seems like it compiles fine for you now, but you're having a runtime-related issue.

(Also, PhreakScript will delete old Asterisk source directories if you use the --force option, so that may have been it.)

What I'm not sure of at the moment is you're seeing something that's unique to your card. I don't think it's a driver issue, since dahdi_hardware seems to show it and that isn't a removed driver... you could try rerunning with the --drivers option, but I'm doubtful that would change anything.

I don't have a card of the same model (TE220), so unfortunately I'm unable to test this further on my end, beyond compilation of the source itself.

[cjemorton]

Interesting... I use Debian for all my Linux servers and I've never had that issue. I've found it to be a good choice as a standard Linux distribution, particularly in terms of compatibility. I can anecdotally say that the vast majority of people I know and service in running Asterisk/DAHDI run a recent version of Debian - not to say that you should too, but it's been relatively issue-free for them and it's more well tested.

Since I'm scratching my head at a loss as to what to do to fix this on Rocky, I think I may do a full clonezilla dump of the system to backup, then install a LTS version of debian, then run your script on it. If I can get it to work bare-bones Debian install. It will definitely isolate the issue to being something related to Rocky. Which it probably is. But this way I can rule it out. I can always dump the image of the disc back onto the system and boot up Rocky again. It just takes a couple hours to get everything dumped back and forth and up and running again. And, I have to stand in-front of my server rack to do it...

Yeah, you probably already know this but obviously Asterisk/DAHDI on a BSD system is a no-no.

Yeah no kidding, I wasn't even thinking of trying to get DAHDI drivers working on FreeBSD.

One of the reasons I was wanting to use Rocky and Linux was to utilize some of the extra left over CPU inside of a LXC container for a few other applications, instead of dedicating a full machine to FreePBX, which mostly sits idle. I was wanting to be able to spin up a few containers on it and run a few things in an isolated docker environment. Docker doesn't play well with FreeBSD outside of Linux compatibility mode. So hence another reason as to why I was targeting Rocky.

https://gitea.osmocom.org/retronetworking/dahdi-linux

Yes the osmocom ones, they did compile for me - but I was still having issues getting them to show up inside of asterisk. There's still something a bit fishy going on IMO. I'm going to keep digging on this. I think I will try running your script on a fresh Debian install see what happens. I realize you don't have the hardware, and there's nothing past checking for it being able to compile that you can do. I do appreciate simply someone to bounce the problem off of. I've been at this for quite awhile now. I think its been most of January since I started the project and it's been one little issue after another. Most of it stems from the DAHDI drivers. Which to me is just silly, they should be well flushed out and supported, they are legacy hardware - you'd think that they'd be well tested and utilized. But I suppose everyone is dropping support for POTS lines and jumping on the full SIP, which is the future of things. Having a POTS line around in power outages is nice and pretty much the primary reason we keep it. Being able to use it inside of asterisk would be nice as well. FreePBX worked for this (I have a complete image of the system with clonezilla, so I can always restore to where I was before.) I just got tired of FreePBX being the bloated mess that it was, and wanted to see if I could put the system to a bit more of a dual purpose.

[InterLinked1]

Interesting... I use Debian for all my Linux servers and I've never had that issue. I've found it to be a good choice as a standard Linux distribution, particularly in terms of compatibility. I can anecdotally say that the vast majority of people I know and service in running Asterisk/DAHDI run a recent version of Debian - not to say that you should too, but it's been relatively issue-free for them and it's more well tested.

Since I'm scratching my head at a loss as to what to do to fix this on Rocky, I think I may do a full clonezilla dump of the system to backup, then install a LTS version of debian, then run your script on it. If I can get it to work bare-bones Debian install. It will definitely isolate the issue to being something related to Rocky. Which it probably is. But this way I can rule it out. I can always dump the image of the disc back onto the system and boot up Rocky again. It just takes a couple hours to get everything dumped back and forth and up and running again. And, I have to stand in-front of my server rack to do it...

Yeah, you probably already know this but obviously Asterisk/DAHDI on a BSD system is a no-no.

Yeah no kidding, I wasn't even thinking of trying to get DAHDI drivers working on FreeBSD.

One of the reasons I was wanting to use Rocky and Linux was to utilize some of the extra left over CPU inside of a LXC container for a few other applications, instead of dedicating a full machine to FreePBX, which mostly sits idle. I was wanting to be able to spin up a few containers on it and run a few things in an isolated docker environment. Docker doesn't play well with FreeBSD outside of Linux compatibility mode. So hence another reason as to why I was targeting Rocky.

https://gitea.osmocom.org/retronetworking/dahdi-linux

Yes the osmocom ones, they did compile for me - but I was still having issues getting them to show up inside of asterisk. There's still something a bit fishy going on IMO. I'm going to keep digging on this. I think I will try running your script on a fresh Debian install see what happens. I realize you don't have the hardware, and there's nothing past checking for it being able to compile that you can do. I do appreciate simply someone to bounce the problem off of. I've been at this for quite awhile now. I think its been most of January since I started the project and it's been one little issue after another. Most of it stems from the DAHDI drivers. Which to me is just silly, they should be well flushed out and supported, they are legacy hardware - you'd think that they'd be well tested and utilized.

They are, and nothing much has changed functionality wise, it's just that every so often there are breaking kernel ABI changes and kernel projects need to keep up with that, or they break.

Not to say they need to be static necessarily - PhreakScript does have a few patches that add features to the kernel-level drivers as well, but I'm not holding my breath over that getting upstreamed anytime soon.

But I suppose everyone is dropping support for POTS lines and jumping on the full SIP, which is the future of things.

See, that's the thing... most people think about this in terms of "trunks", but the more common usage of DAHDI that I see these days is for local extensions, not for connecting to a provider. I have a channel bank and an analog card in service here, and most of my analog phones connect to that. It's much more feature rich to use DAHDI with analog phones than SIP. SIP is not and never was designed for analog phones connecting to a Class 5 end office. There is a lot of stuff with analog phones that you can only do with chan_dahdi and none of the other channel drivers, since it requires complete control of the phone line, which T1 family signalling (mostly) gives you.

So my personal prediction is yes, it's less common to connect to POTS lines with FXO cards, perhaps, but DAHDI will continue to remain relevant for those that want the "premium" analog phone experience, as I do.

Having a POTS line around in power outages is nice and pretty much the primary reason we keep it.

Yes, agreed with you there! (Sadly, my POTS line is over fiber, but I do have lead acid batteries for it).

Being able to use it inside of asterisk would be nice as well. FreePBX worked for this (I have a complete image of the system with clonezilla, so I can always restore to where I was before.) I just got tired of FreePBX being the bloated mess that it was, and wanted to see if I could put the system to a bit more of a dual purpose.

FreePBX is definitely a mess so I totally agree with you about moving away from that. I think you'll be happy with using Asterisk "directly" as it was meant to be used.

[InterLinked1]

I'm going to push the changes so far that will close this issue as "resolved", since it fixes the Rocky stuff, but feel free to keep following up in the comments! (or open a separate issue, if notice something different).

[InterLinked1]

One of the reasons I was wanting to use Rocky and Linux was to utilize some of the extra left over CPU inside of a LXC container for a few other applications, instead of dedicating a full machine to FreePBX, which mostly sits idle. I was wanting to be able to spin up a few containers on it and run a few things in an isolated docker environment. Docker doesn't play well with FreeBSD outside of Linux compatibility mode. So hence another reason as to why I was targeting Rocky.

I meant to comment on this earlier, but I guess I forgot...

I would not recommend virtualizing a DAHDI environment, under any circumstances. It just tends not to work well. I always (and always recommend) running it on bare metal. It's very sensitive to IRQs and interrupt latency and things of that nature.

I actually recently heard about the idea of using the realtime kernel instead, and might even give that a try...

[cjemorton]

I actually recently heard about the idea of using the realtime kernel instead, and might even give that a try...

Interesting. If you hear more on this let me know. I'm down to try out some fun stuff. I've got Debian 12 loaded and I'm about to try out your script on there. I'll see how things go.

[InterLinked1]

I actually recently heard about the idea of using the realtime kernel instead, and might even give that a try...

Interesting. If you hear more on this let me know.

A couple people on the PhreakNet mailing list[1] had mentioned this, that had tried or had experience with it. I haven't tried that yet, but I'm tempted to in the future, if/when I set up another physical machine for testing.

[1] https://groups.io/g/phreaknet

I'm down to try out some fun stuff. I've got Debian 12 loaded and I'm about to try out your script on there. I'll see how things go.

Sounds good, let me know!