Hi Ian,
> On Jun 2, 2017, at 13:58, Ian MacDonald via PacketFence-users
> <packetfence-users@lists.sourceforge.net> wrote:
>
> This was very helpful and immediately brought us to conclude it was related
> to a change in our certs, that we opportunistically pushed out, as a root
> cause of our issue. Is there a place in the docs that describes how to get
> these debug outputs, to better help us help ourselves in the future?
Unfortunately, each daemon has it's own ideas as to what constitutes "debug
mode" and how to trigger it.
Some are much better at it (e.g. FreeRADIUS) than others.
I had to learn by trial and error myself, at least for those services where
Inverse did not write the code (e.g. Apache).
In general, you can have a look at systemd to see what is the actual executable
that is run for a service.
You can get that information from the "ExecStart" line in the systemctl output.
From there it's mostly a trip to the manpage for it, trying to run it with
--help, or reading the source if it comes to that.
Some examples:
FreeRADIUS has excellent debugging features, which are well documented.
man radiusd (or man freeradius on debian) shows for example the -X and -C flags
which can be used to check for syntax or run the server in debug mode.
Additionally you can use "raddebug" to debug a live server without restarting
and even filter requests so that only the ones matching a condition will
trigger the debug mode.
Kudos to the FreeRADIUS team.
Apache has a -X mode, as indicated in man httpd (on CentOS, which I have in
front of me at the moment).
ISC DHCPd has -f and -d switches to force a process to stay in the foreground
and log to STDERR.
man winbindd shows switches for --foreground, --stdout, and --debuglevel.
In addition, the log level of most PacketFence services can be configured
through the conf/log.conf and conf/log.conf.d/* files.
Changing the loglevel from INFO to DEBUG can be helpful, but would not have
helped in your case since the service was not even starting.
>
> The actual issue was that even though the cert, key and intermediate were
> concatenated together into the .pem file, in the right order, one of the
> files had different LF/CR formatting (windows vs linux), something introduced
> by our ca, that was not obvious, and did not affect applying the same files
> to the configuration GUI (nor any other system using the same wildcard
> certs).
>
> On a note related to upgrade in general, our team saw the release for 7.1,
> which we are excited about with the inclusion of Ubiquiti devices, and I had
> some comments back on the upgrade process that might help clarify things for
> other users upgrading and using the UPGRADE.asciidoc as a reference. We
> think it would be worthwhile to tell people to explicitly execute the Version
> specific steps prior to the Distribution specific steps. Some justification
> follows.
>
> We knew from our v6.5 to 7.0 upgrade that the section for "Upgrading from a
> version prior to 7.1.0" had to be executed before the section for "Debian
> based systems" because it would not make sense to not upgrade the MariaDB
> first. For anyone who started on v7.0.1 or later and who might
> appropriately skip the "Upgrading from a version prior to 7.0.0" section, it
> really is not clear which group of steps you should execute first -> i.e.
> Should the user perform the Distribution specific steps before the Version
> specific steps or vice-versa. It does hint in the doc that 'some steps may
> be required to be done BEFORE the packages upgrades' but it never really
> says clearly 'Go do all the Version specific steps further down the document
> before you come back up and do your distribution-specific steps'. Anyone
> that reads it all, and just executes in order, would (we think) be doing it
> in the incorrect order.
>
Fair points, all of them.
We'll try to do better and be more explicit in the future.
Best regards,
--
Louis Munro
lmu...@inverse.ca <mailto:lmu...@inverse.ca> :: www.inverse.ca
<http://www.inverse.ca/>
+1.514.447.4918 x125 :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu <http://www.sogo.nu/>) and
PacketFence (www.packetfence.org <http://www.packetfence.org/>)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
