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. -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/f7d1975d-e9c5-4934-af56-20b84f76810an%40googlegroups.com.
