networkupstools / nut-website Goto Github PK

Recent generations of https://networkupstools.org/stable-hcl.html list the manufacturer/model/driver column contents as b'some string' markup, which may be Python for "binary". Probably have to append .encode('utf-8') (or similar) somewhere to rectify.

(is this on a branch somewhere?)

networkupstools/nut#566

For example, now that we have had a long time passed after the last (2.7.4) official release, there is a large gap between content that can be relevant to users of distro-provided NUT packages vs. current information matching the evolving codebase on github. Hopefully future gaps will be smaller, but still inevitable.

I have experimented with this a bit, and concluded that GitHub Pages integration only allows one web-site per organization. There can be additional repositories with Pages enabled, whose repo name is a "sub-URI" in that one website.

We can use sub-domain names with web-redirection from Gandi DNS+ hosting to point from "simple" (and non-SSL) Web server names like http://master.networkupstools.org/ to the URI we want, but then the users would browse unwieldy https://networkupstools.org/networkupstools-master.github.io/ (where "networkupstools-master.github.io" comes from https://github.com/networkupstools/networkupstools-master.github.io/ repo).

A possibly better solution would be to use just one git repository for the resulting generated website, but define a sub-directory structure for data populated from release-tagged NUT/NUT-DDL(/...?) sources. This way the main site evolves as it did, generating stuff from master branches, and the frozen-in-time sub spaces are generated once. There is probably some content that might cause their regeneration (changes to page layout? bottom-banners especially if dictated by sponsors/partners? left menu?..) but that would be rare - at least, original version-dependent content should remain.

This approach may however need re-engineering of some generated links (e.g. there is no point storing historic archives many times), though there may be some mess around NUT DDL (especially for "new" datapoints about discovered device support with older NUT releases)...

I get the following error in OS X:

sort: stray character in field spec: invalid field specification `4.1,4.5rV'

The man page on FreeBSD also indicates that sort does not support dots in the field specification.

This is a pretty low-priority bug, but eventually I would like to add an autoconf test to see if "gsort" is installed.

This requires specifying a codebase to Buildbot, and filtering the commits in both schedulers.

Also, it may be preferable to have a separate builder to handle man pages and documentation outside of the website update cycle (or we should add a step to automatically update the nut submodule).

networkupstools/nut#186
check if in git

We have a link (http://www.networkupstools.org/lists/) on the Alioth Mailman info pages (e.g. http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser) which is dead, and the Alioth setup isn't allowing edits at the moment. The list link should probably redirect to http://networkupstools.org/support.html instead.

networkupstools/nut#808
check if in git

https://networkupstools.org/ups-protocols.html
-> https://www.usb.org/document-library/power-device-class-document-10

Spellcheck jobs on Travis CI keep complaining about words in nut-website text files that are covered in nut/doc/nut.dict that is supposedly used. Similar runs on local workstation work without errors.

It is possible that the spellcheck related Makefile hardcodes a bit too much, so I began experimenting with a more flexible mechanism that could be more easily and reliably hijacked by consumers from other Makefiles (man pages subdir did so etc. already, website now also a focus point).

For now "fixed" manually. Possibly stems from alphabetic sort etc. instead of git history? Or just not regenerated even after posting the historic-release and master versions of the site?

Need more investigation; should have used tag-based PACKAGE_VERSION or similar...

@zykh: When Buildbot tries to build the website, it runs a "git clean -fdx" in the nut-website checkout ("~buildbot/slaves/buildslave-cayman/Debian-website/build/") to clean everything that isn't version tracked, and runs the same command in the nut submodule directory.

When running ./autogen.sh, it throws the error shown here:

http://buildbot.networkupstools.org/public/nut/builders/Debian-website -> latest build (currently 17) -> configure/stdio

Readying NUT Website
----------------------------------------------------------------------
Calling autoreconf...
configure.ac:19: error: possibly undefined macro: AC_MSG_RESULT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:22: error: possibly undefined macro: AC_MSG_ERROR
autoreconf: /usr/bin/autoconf failed with exit status: 1

If I re-run ./autogen.sh manually, it completes, but then configure complains:

$ ./configure
Network UPS Tools - Website (NUT version 2.7.1)
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
./configure: line 2213: NUT_CHECK_ASCIIDOC: command not found
checking if asciidoc version can build website (minimum required 8.6.3)... ./configure: line 2217: syntax error near unexpected token `${ASCIIDOC_VERSION},'
./configure: line 2217: `AX_COMPARE_VERSION(${ASCIIDOC_VERSION}, ge, 8.6.3,'

Same version of autoconf as on OS X (which works the first time that ./autogen.sh is run), but automake is a little older:

$ autoconf --version
autoconf (GNU Autoconf) 2.69
$ automake --version
automake (GNU automake) 1.11.6

Related to issues #34 and networkupstools/nut#1949

Maybe magic text in annotated tag or having been signed can be a clue.

Also note

NUT repository has a number of tags for intermediate milestones during development, which are not releases (candidates, major side project merges).

However the website links from https://networkupstools.org/download.html#_stable_tree_2_8 seem to report just the newest (possibly annotated) git tag => inspired link. For example, at the moment it suggests http://www.networkupstools.org/source/2.8/nut-2.8.0-Windows.tar.gz which is not even published among sources (separate repo) which may in fact be a criterion for choosing what maintainers think is a release - just pick the newest of those.

It appears that we have not included /protocols/snmp in this git repository. This mostly seems to be copies of MIB files.

Results of #12 and #13 / #14 are not seen in the codebase... like someone force-pushed to master and erased recent commits?

The code is still available in https://github.com/networkupstools/nut-website/tree/pull_404 branch BTW (up-to-date with my devel fork version). There are some merge conflicts reported ATM, to look at when we have time :-)

As in many other places, the UPS mention is extraneous and not true, since we also have PDU and ATS at least.

So rename the ups-protocols page and mentions to simply "protocols".
This is spread across several repositories:

• nut
  ** docs/documentation.txt:- link:ups-protocols.html[UPS protocols library]
  ** docs/documentation.txt:- link:ups-protocols.html[UPS protocols library]
  ** docs/acknowledgements.txt:link:ups-protocols.html[extensive information] on its USB/HID devices, along
  ** docs/acknowledgements.txt:provided link:ups-protocols.html[all protocols information]. Elio Parisi has
  ** drivers/blazer.c: * found online at http://www.networkupstools.org/ups-protocols/megatec.html
  ** drivers/riello_usb.c: * http://www.networkupstools.org/ups-protocols/riello/PSGPSER-0104.pdf
  ** drivers/riello.h: * http://www.networkupstools.org/ups-protocols/riello/PSGPSER-0104.pdf
  ** drivers/riello.h: * http://www.networkupstools.org/ups-protocols/riello/PSSENTR-0100.pdf
  ** drivers/riello_ser.c: * found online at "http://www.networkupstools.org/ups-protocols/riello/PSGPSER-0104.pdf"
  ** drivers/riello_ser.c: * and "http://www.networkupstools.org/ups-protocols/riello/PSSENTR-0100.pdf".
  ** drivers/delta_ups-mib.c: * MIB reference: http://www.networkupstools.org/ups-protocols/snmp/DeltaUPSv4.mib
  ** drivers/riello.c: * http://www.networkupstools.org/ups-protocols/riello/PSGPSER-0104.pdf
  ** drivers/riello.c: * http://www.networkupstools.org/ups-protocols/riello/PSSENTR-0100.pdf
  ** NEWS: http://www.networkupstools.org/ups-protocols.html#_riello
• nut-website
  ** Makefile.am: ups-protocols.html
  ** rename ups-protocols.txt to protocols.txt

I had a community chat yesterday with a guy who wanted to configure an UPS for their systems, and pointed them to NUT. Happens they did not know of it (last UPS set up with apcupsd 10 years ago, never looked into this area since). A near-instant feedback was that the NUT website (front page) is pretty hard to navigate for the real newcomers - like to understand what the project does at all, how it's layered etc.

I passed them the direct links in the chat, but they were 2-3 clicks away and that's if you know where to click :)

So just FYI - readability and usability is a real-life issue ;)

Maybe a good start would be a top-link to page marked as "Newcomer Intro" or some such, with a mix of overviews from user and devel guides and the feature page (but less white space and huge headers than the latter).

Hello,

Not so much of an issue, but more of an inquiry. I have a HP Micro Mini setup running home assistant and I connected my CyberPower UPS to it via the USB cable. I added the NUT addon and integration. All works well. Very happy with it. I do have two other UPS's in my home that have a RMCARD205 in them. I am not sure if this is even possible without the use of a small Raspberry Pi, but can I somehow have two instances of nut and one of which would connect via Ethernet. The HP Micro Mini and both RMCARD205's are on the same vlan. Any help and suggestions would be appreciated.

In the list of projects, there is a reference to Winnutclient on the sourceforge site.
However, this project has not been maintained since 2015 and I personally took over the development from Github : WinNUT-Client
The project has evolved considerably and I am quite active in its development.

I would be grateful if you could update the corresponding projects page.

To point at the official and staging websites

Reminder from @aquette

Reminder from @aquette : improvement over the 1rst gen website generator (as currently used with networkupstools.org)

For asciidoc + bootstrap, it mainly relies on the J's/ subdir plus this asciidoc conf for bootstrap:
https://github.com/42ity/42ity-org-website/blob/master/bootstrap.conf

And a bit of salt in the Makefile too.

As per http://laurent-laville.org/asciidoc/bootstrap/, the version in 42ity is the latest (2015 😕). So no need to update the integration

These versions of documents seem to be rendered and cross-referenced with anchors more consistently than chunked-HTML (and single-PDF) docs, as explored in networkupstools/nut#1957 as well as having a single file-name is more future-proof for persistent links. Publishing them on NUT website could facilitate linking from documents, mails, wikis, etc.

networkupstools.org presents an invalid GitHub SSL certificate:

$ openssl s_client -connect networkupstools.org:443 
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = *.github.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

This is especially problematic when trying to download NUT, e.g. when packaging it:

$ wget 'http://www.networkupstools.org/source/2.7/nut-2.7.4.tar.gz'
--2017-04-23 11:13:45--  http://www.networkupstools.org/source/2.7/nut-2.7.4.tar.gz
Resolving www.networkupstools.org... 151.101.12.133
Connecting to www.networkupstools.org|151.101.12.133|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://networkupstools.org/source/2.7/nut-2.7.4.tar.gz [following]
--2017-04-23 11:13:45--  https://networkupstools.org/source/2.7/nut-2.7.4.tar.gz
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving networkupstools.org... 192.30.252.154, 192.30.252.153
Connecting to networkupstools.org|192.30.252.154|:443... connected.
GnuTLS: A TLS warning alert has been received.
GnuTLS: received alert [112]: The server name sent was not recognized
The certificate's owner does not match hostname ‘networkupstools.org’

I'd like to suggest a few changes be made to the Projects page to bring it up to date as best as I can find.

• KNutClient: Last available version of the website seems to be from October 2020. It doesn't seem to be in any other live locations besides Ubuntu and Debian distros. Move to Legacy section?
• NUT-Monitor: Last update in 2010 - move to Legacy?
• Windows NUT Client/winnutclient: Accurately stated; the original client on Windows! Consider moving to legacy section?
• WinNUT-Client: Accurate description, but please update to the latest URL. I haven't been able to contact @gawindx in years so I've forked in and continued development. I'm also working on a set of .Net libraries in the same organization for interacting with the NUT protocol (both from a client and mock-server's point of view) if that's at all interesting.
• WinNUT: Perhaps the primary description can be distilled down to the mention that it's currently being worked on by the main networkupstools organization, and link to that. If desired, perhaps the history can be moved down to the legacy section.

Setting up an environment to make and test changes myself seemed a little daunting so I'm not sure I can get to this straight away, but hopefully this is helpful as a starting point.