wee_debug and new user support

[Vince Skahan]

I'm noticing a growing pattern of new users posting to weewx-user along the lines of "I know nothing of Linux but I tried to install weewx and it doesn't work.  Will somebody please help me". 

Think we need a "how to report problems" page more tailored to non-Linux users perhaps.   We're seeing a growing percentage of new pi non-unix non-shell users.  That's good of course, but they don't meet the longstanding minimal user expectations nor will they ever.  Many are just not going to spin up on Linux nor shell etc.  They just want to install weewx and never look at it again.  That's ok too.

I also keep thinking about the origin of wee_debug and wonder if it's a bit too heavyweight for 'initial' problem forensics especially when we try to get new users to run it when they are not shell type users.

So basically I'm wondering if the default wee_debug output should be tweaked to be a bit more minimalist and more catered to supporting the ever-growing set of non-linux-fluent new users.

Some suggestions:

• all verbosity levels include obfuscated weewx.conf in the output.  Mine is over 900 lines long.  That's too long for a new user to cut+paste.   Suggest changing the default verbosity to '0' and having that level 'not' include weewx.conf at all.   Add a command-line switch to include weewx.conf only when explicitly asked for.

• user/pass/key obfuscation isn't perfect, nor can it probably ever be.   I did find one edge case where it failed to filter out some things I had in commented out lines.  Suggest tweaking the obfuscation to not include commented out lines to at least handle that edge case.

• some users get confused how they installed weewx and do things like use packages to update when their old installation was setup.py - not quite sure if that can be prevented, but wee_debug should at least report which way(s) weewx was installed on the system

• some users get confused re: systemd and whether it's using service files or init.d backward compatibility.  Tougher issue to work, but wee_debug should report how the startup file is hooked into the init subsystem

• many (MANY) pi users don't realize that their os does not install and enable a webserver by default.   Wonder if wee_debug can look to at least see if nginx and/or apache are installed (and running?) on the system.

wee_debug is great stuff, but I'm thinking some minor tweaks might help a lot in helping us support new users as well as the higher expertise/initiative folks weewx originally was targeted for.

Thoughts ?

[mwall]

On Wednesday, April 14, 2021 at 2:32:35 PM UTC-4 vince wrote:

I'm noticing a growing pattern of new users posting to weewx-user along the lines of "I know nothing of Linux but I tried to install weewx and it doesn't work.  Will somebody please help me". 

Think we need a "how to report problems" page more tailored to non-Linux users perhaps.   We're seeing a growing percentage of new pi non-unix non-shell users.  That's good of course, but they don't meet the longstanding minimal user expectations nor will they ever.  Many are just not going to spin up on Linux nor shell etc.  They just want to install weewx and never look at it again.  That's ok too.

I also keep thinking about the origin of wee_debug and wonder if it's a bit too heavyweight for 'initial' problem forensics especially when we try to get new users to run it when they are not shell type users.

the quantity of information is not a problem.  users' ability to run the tool and post the output is the problem.  lets make that easier.

• all verbosity levels include obfuscated weewx.conf in the output.  Mine is over 900 lines long.  That's too long for a new user to cut+paste.   Suggest changing the default verbosity to '0' and having that level 'not' include weewx.conf at all.   Add a command-line switch to include weewx.conf only when explicitly asked for.

keep weewx.conf in the output.  contents of weewx.conf are often the most obvious indicator of a problem.

 

• user/pass/key obfuscation isn't perfect, nor can it probably ever be.   I did find one edge case where it failed to filter out some things I had in commented out lines.  Suggest tweaking the obfuscation to not include commented out lines to at least handle that edge case.

probably worthwhile for wee_debug to run a second obfuscation pass after it has generated its output.  that would catch commented items. 

 

• some users get confused how they installed weewx and do things like use packages to update when their old installation was setup.py - not quite sure if that can be prevented, but wee_debug should at least report which way(s) weewx was installed on the system

how weewx was installed is pretty obvious from weewx.conf combined with the first few lines of the log output.  and that is direct, not inferred information.

 

• some users get confused re: systemd and whether it's using service files or init.d backward compatibility.  Tougher issue to work, but wee_debug should report how the startup file is hooked into the init subsystem

we need to update weewx debian installer so that it detects systemd and installs unit file for systemd and rc script for non-systemd systems.

also convert to weewx-multi everywhere, so that extending to multiple weewx instances is just a matter of modifying the /etc/default/weewx file, whether you are on a systemd system or non-systemd system.  (this might not be possible on systemd systems - might have to do multiple unit files, but i need to do more testing to be certain)

 

• many (MANY) pi users don't realize that their os does not install and enable a webserver by default.   Wonder if wee_debug can look to at least see if nginx and/or apache are installed (and running?) on the system.

including peripheral information in wee_debug could be helpful.  for example, query to see if mysql/maria is installed and enabled.  query to see if nginx/apache is installed and enabled.  query to see if sqlite cmd-line tools are available.  query to see if pyephem and other python dependencies and suggestions/often-used packages are installed.

[mwall]

it might be worthwhile to add a mechanism to wee_debug that makes it trivial to post the wee_debug output to weewx user group, or to email the output to the user so that the user can then forward that to weewx user group.

of course it should do the standard thing of sending output to stdout.  but add an option to send to file (in case users don't know how to pipe or cat), and add an option to send as email to an address (which of course assumes that user has a working email configuration on the device on which wee_debug is running).

[Karen K]

mwall schrieb am Samstag, 17. April 2021 um 15:12:20 UTC+2:

of course it should do the standard thing of sending output to stdout.  but add an option to send to file (in case users don't know how to pipe or cat), and add an option to send as email to an address (which of course assumes that user has a working email configuration on the device on which wee_debug is running).

I guess there is often no e-mail configuration, especially if a Raspberry Pi is used.

But to think that idea further, wee_debug could have an option to create an HTML file and store it to HTML_ROOT. The user can then open it with their browser and create a PDF file to attach to the message to be sent to the user group.

[Vince Skahan]

On Saturday, April 17, 2021 at 6:07:01 AM UTC-7 mwall wrote:

the quantity of information is not a problem.  users' ability to run the tool and post the output is the problem.  lets make that easier.

Agree.  Maybe that's the real problem why it's not used much.

keep weewx.conf in the output.  contents of weewx.conf are often the most obvious indicator of a problem.

 

Sure.    If it's easier to post the output then how long the output is might not matter much.

 

probably worthwhile for wee_debug to run a second obfuscation pass after it has generated its output.  that would catch commented items. 

The obfuscation uses ConfigObj, so some other method using regex or the like would be needed for stronger obfuscation.  I'd suggest removing all whitespace lines, all lines with whitespace+comments, and even all comments at the end of a line to make it 'really' certain it's obfuscated.

 

how weewx was installed is pretty obvious from weewx.conf combined with the first few lines of the log output.  and that is direct, not inferred information.

 

In general, yes, but we've seen folks with multiple installations (one setup, one packaged) and wee_debug only reports based on the .conf file you tell it to use.   This is why I'm suggesting to just check for both places weewx.conf might be present in, just in case, and flag it if it finds two installations present.

 

we need to update weewx debian installer so that it detects systemd and installs unit file for systemd and rc script for non-systemd systems.

 

That would be ideal.  We see lots of threads from folks trying to force systemd into the installation after the fact.   An update path would have to remove the init.d file if found though, or at least move it aside and disable trying to use it.

also convert to weewx-multi everywhere, so that extending to multiple weewx instances is just a matter of modifying the /etc/default/weewx file, whether you are on a systemd system or non-systemd system.  (this might not be possible on systemd systems - might have to do multiple unit files, but i need to do more testing to be certain)

 

At the point where we want to go more toward /etc/default/weewx (or /etc/sysconfig/weewx for RHish), is it worth thinking about going all the way there ?  

Perhaps move all the things needed to minimally get weewx set up out of weewx.conf and into a longer /etc/default file, more like the operating systems expect ?    

That might be a bit too much, given weewx being all-in on configobj, but maybe there's some way to reach a middle ground where the minimum is in /etc/default and the gory internals stuff is still in weewx.conf perhaps.

 

• many (MANY) pi users don't realize that their os does not install and enable a webserver by default.   Wonder if wee_debug can look to at least see if nginx and/or apache are installed (and running?) on the system.

including peripheral information in wee_debug could be helpful.  for example, query to see if mysql/maria is installed and enabled.  query to see if nginx/apache is installed and enabled.  query to see if sqlite cmd-line tools are available.  query to see if pyephem and other python dependencies and suggestions/often-used packages are installed.

I was originally thinking just webserver (the most frequent miss by new pi users) but yes at least the minimal python dependencies would be good.  I'm not sure whether wee_debug would even run if some of them aren't met (configobj to name one for certain).

The other thing to note is that how you call wee_debug matters especially when looking for python dependencies.  Did I add pyephem via package or pip ?

You have to call it with the interpreter weewx is configured to use.   In my example, I have a native python2 system that I added python3 to manually by compiling my own.  The system default is python2.  So I had to run 'python3 /home/weewx/bin/wee_debug' for it to work.  Perhaps an edge case nowadays as most systems other than RedHat.old are native python3 finally.

(re: your other followup)

Not sure how to work posting to the weewx-user group.  None of my weewx systems have 'ever' been able to email anywhere, nor will they.

Of course if you wanted to go clean sheet of paper, we could generate JSON debug output that some future automated processor could reduce and flag errors on, but that leads you down a much longer path.

[gjr80]

On Sunday, 18 April 2021 at 04:09:22 UTC+10 vince...@gmail.com wrote:

On Saturday, April 17, 2021 at 6:07:01 AM UTC-7 mwall wrote:

 

the quantity of information is not a problem.  users' ability to run the tool and post the output is the problem.  lets make that easier.

Agree.  Maybe that's the real problem why it's not used much.

We have words at the top of the weewx-user page tell users to post certain details, they frequently don’t. I suspect the real reason that wee_debug is not used is because users don’t know about it and those that do ignore it. I don’t believe we will easily change that (user) behaviour. I am resigned to having to tell users to use it just as we have to tell them to include a log extract or set debug=1.

 

probably worthwhile for wee_debug to run a second obfuscation pass after it has generated its output.  that would catch commented items. 

The obfuscation uses ConfigObj, so some other method using regex or the like would be needed for stronger obfuscation.  I'd suggest removing all whitespace lines, all lines with whitespace+comments, and even all comments at the end of a line to make it 'really' certain it's obfuscated.

Configobj is just used to parse weewx.conf and obtain a dict. Everything is there, comments and all but the obfuscation code only looks for dict keys that start with the item of interest. It could be as simple as changing a ‘startswith’ to ‘in’, certainly should not be difficult.

how weewx was installed is pretty obvious from weewx.conf combined with the first few lines of the log output.  and that is direct, not inferred information.

 

In general, yes, but we've seen folks with multiple installations (one setup, one packaged) and wee_debug only reports based on the .conf file you tell it to use.   This is why I'm suggesting to just check for both places weewx.conf might be present in, just in case, and flag it if it finds two installations present.

 

They beauty of wee_debug is that it gives you the config, details etc for the WeeWX install that will be run if the user starts WeeWX in the usual way. So we are not relying on th3 user to determine what is being run. This is often overlooked and I believe a strength of wee_debug. By all means state if there are multiple install types but wee_debug should continue to only provide details on the ‘default’ install.

The other thing to note is that how you call wee_debug matters especially when looking for python dependencies.  Did I add pyephem via package or pip ?

You have to call it with the interpreter weewx is configured to use.   In my example, I have a native python2 system that I added python3 to manually by compiling my own.  The system default is python2.  So I had to run 'python3 /home/weewx/bin/wee_debug' for it to work.  Perhaps an edge case nowadays as most systems other than RedHat.old are native python3 finally.

wee_debug is no different to any of the other utilities, if you need a special incantation for wee_debug you will need the same incantation to run wee_database, wee_reports etc.

(re: your other followup)

Not sure how to work posting to the weewx-user group.  None of my weewx systems have 'ever' been able to email anywhere, nor will they.

Of course if you wanted to go clean sheet of paper, we could generate JSON debug output that some future automated processor could reduce and flag errors on, but that leads you down a much longer path.

I’m not sure I see the benefit of emails, pdfs, json etc. if the wee_debug out is dumped to a text file it can be transferred and posted anywhere without need to more software. Looking at the wee_debug code again I think the piping to file may have been affected by the python 2/3 conversion. I see a few six compatibility calls in and around the writing to stdout. We might have to revisit how that is done.

Gary