* [mod_amqp] Adjusting to Appropriate Log Level for Message
Refined Logging Level for FreeSWITCH's mod_amqp: The logging level for the AMQP module in FreeSWITCH has been updated from 'warning' to 'debug'. This adjustment ensures a more suitable level for the log message and eliminates any potential impact on production environments. Previously, the 'warning' level would lead to unnecessary log entries for each individual message, although there was no actual warning condition. This change improves logging efficiency and appropriateness for mod_amqp's operations within FreeSWITCH.
* [MOD_AMQP] Change LogLevel to DEBUG1 as it is more appropriate for this message
* [ldns] config.h change to not define inline under Windows to avoid clash with Windows winsock2.h inline usage
* [Build-System] Use updated ldns tarball on Windows.
---------
Co-authored-by: Andrey Volk <andywolk@gmail.com>
On several installs on recent Debian and Ubuntu systems, I have noticed
that GID 999 is already allocated on the system running the container,
making it a minor hassle to share a common freeswitch UID and GID
between the Docker host and the container.
The conflicting group id varies, but is typically either one of the systemd
groups or polkitd, which are dynamically created when those packages are
installed. The behavior stems from the range of system GIDs being
between 100-999 ([see Debian Policy 9.2.2](https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes))
and the fact that system installation dynamically allocates from this
range. I didn't track down exactly why these daemons are allocating
from the top of the range, since the default behavior of `adduser` and
`addgroup` ([link](6c04aa701a/adduser (L1255-1269)))
is to search from the bottom of the range, and the manpage for
`groupadd` says that it's default is also to use the smallest id,
but perhaps it was to avoid (other) conflicts.
The approach taken in this PR is to default to 499, more in the middle
of the range, which should reduce the chance of conflicting with an
existing system UID and GID. The values are also now exposed as ARGs
and so can be explicitly set during the build with
`--build-arg="FREESWITCH_UID=xxx"` and `--build-arg="FREESWITCH_GID=yyy"`
if desired.
The conference output loop accesses the member's read_impl while
resampling. The output loop also spawns off the input loop thread, which
is where the member->read_impl is actually initialised. This results in
an uncommon race where the output loop sometimes gets an uninitialised
member->read_impl and bails with logs something like this:
2023-10-12 18:19:01.436844 [DEBUG] conference_loop.c:1340 Setup timer soft success interval: 20 samples: 960 from codec L16
2023-10-12 18:19:01.436844 [DEBUG] conference_loop.c:1497 Outbound conference channel answered, setting CFLAG_ANSWERED
2023-10-12 18:19:01.436844 [NOTICE] switch_core_media.c:15852 Activating write resampler
2023-10-12 18:19:01.436844 [DEBUG] switch_core_media.c:16097 Engaging Write Buffer at 1920 bytes to accommodate 0->1920
2023-10-12 18:19:01.436844 [ERR] switch_core_media.c:16112 Write Buffer 0 bytes Failed!
As a solution, we initialise the member->read_impl even before we start
up the input loop, so that this race can never happen.
* [Core] Coverity: 1500270 Use of 32-bit time_t
* [Core] Coverity: 1500229 Use of 32-bit time_t
* [Core] Coverity: 1500235 Use of 32-bit time_t
* [Core] Coverity: 1500244 Use of 32-bit time_t
* [Core] Coverity: 1500250 Use of 32-bit time_t
* [Core] Coverity: 1500245 Use of 32-bit time_t
* [Core] Coverity: 1500255 Use of 32-bit time_t
* [Core] Coverity: 1500370 Use of 32-bit time_t
* Cleanup
* default to Debian bookworm
* use DEBIAN_VERSION instead of lsb_release; gosu is in Debian since buster
* update comments for FS_META_PACKAGE and exposed ports
* fix SHELL invocation so 'RUN' works as expected in downstream builds
See: https://docs.docker.com/engine/reference/builder/#shell
* [contrib/timezone-gen] Move timezone-gen.pl to own folder
* [contrib/timezone-gen] Add fixTzstr
* [contrib/timezone-gen] Add tests and zone data getter
- tests.pl can be used to verify that the generated timezone conf
will produce the correct datetimes by testing them against
what the system's `date` says
- build-zonedata.pl will download the latest tzdb data and build
the posix timezone data files. It only builds what is needed
rather than adding extraneous "right/" and "posix/" timezones.
FreeSWITCH doesn't seem to be able to use the "right/"
timezone files.
- data/ is where the various files needed to generate the
timezones gets stored
ovadbar
mahald
Visytel
tmancill
Andrey Volk
Jakub Karolczyk
Arun Raghavan
Dragos Oancea
Douglas Vought
Sergei Rozhkov
Len
António Silva
Matteo