• Posts

  • Joined

Everything posted by uberchuckie

  1. Let's hope a 6.5.54 image is released soon. It fixes the Log4j remote code execution vulnerability.
  2. The UI does come up but for the first run, it takes a minute or two to initialize the database. If you tried to logon right away, it won't work. If you stopped the container while it was still creating the database schema, it won't be initialized properly. Stop the container, delete the appdata directory for observium and start it again. Wait for the database schema creation to complete. You can monitor it from the log file.
  3. @Hamsterman Someone else asked about this and I took a quick look. You can edit the config.php file and change the $config['base_url'] config line to the URL you need.
  4. You can change the host port but not the container port. It's configured and exposed when the container image is created. I assume there are parts of observium that references the port when it builds the URL. To change the container port, you'll have to fork the repository and run your own image.
  5. Use "removepkg" to remove any packages you have manually installed. The Nerd Pack cannot install or upgrade any packages that you have upgraded manually.
  6. I created a test image yesterday based on phusion's alpha Ubuntu 20.04 based baseimage. It seems to work from my short testing. The biggest change is upgrading Python to 3.8 from 2.7, the latter of which has reached End-Of-Life awhile back. I've tagged the image as focal-alpha if people want to try it out. Observium and MariaDB doesn't change in this image so there shouldn't be any differences other than upgraded libraries. Again, this is just for testing or if you were curious, I wouldn't upgrade right now if you depend on it working correctly.
  7. I just checked again, all the timezones are set correctly in my container. I'm still seeing graphs in UTC.
  8. Yeah, I don't think anyone has figured it out yet.
  9. I fixed the problems with dig and nslookup. Note that this upgrades json-c. /usr/lib64/libjson-c.so.4 is replaced with /usr/lib64/libjson-c.so.5. I don't know what else relies on the older version of json-c.
  10. Updated bind. Let me know. I think the latest bind version broke dig. dig was working on my system before I inadvertently updated it. (I removed the libraries that are found on the list) /usr/lib64/libjson-c.so.4 exists but not version 5. Maybe the latest version of bind added kerberos support from krb5. /usr/lib64/krb5 only contains winbind_krb5_locator.so nslookup has the same library dependency issue.
  11. WireGuard working fine for me with PIA as well. Getting much better throughput with WireGuard than OpenVPN. I think it was CPU bound due to OpenVPN being single threaded.
  12. @seanwalter Thanks for helping to debug. You can switch back to the latest tag as all the fixes have been applied to it.
  13. The new version 3.0 image is working for me both upgrading from the previous image and from scratch. I've updated the latest tag. Please switch back to the latest tag if you've tested the other tags. Thanks.
  14. Good to hear! Thanks for helping me diagnosing this problem.
  15. @chip You can retry now with the 3.0_beta tag. Just click on "Check for Updates" to pick up the new container image.
  16. @chip @seanwalter I think I've fixed it. I have updated the 3.0_beta tag with the fix. If everything goes well, I'll push all the updates to the latest tag. @seanwalter Please backup your data before you try it. The 3.0_beta tag contains Observium 20.9 and would perform an irreversible schema update. Thanks for your patience to help me track down this bug. The pull request for the fix is: https://github.com/charlescng/docker-containers/pull/8
  17. The problem is related to the MariaDB 10.4 -> 10.5 upgrade. The some of the configuration that is to be rewritten in the my.cnf has moved. I'll look into fixing it when I have time.
  18. OK, I think I know what's going on. When MariaDB first starts with the script to bootstrap itself, it's using the mysql:mysql user/group (104:106). The script changes the ownership to nobody:users (99:100) and causes the file permission issues. This has always been the behaviour and I don't know why this doesn't fail for others but fail for some. It makes sense that changing the permissions to 777 works for you. My host doesn't have user 104 and group 106 defined. Maybe this is why it's working. I'll need to think about how to fix this without breaking it for others.
  19. @chip Can you delete everything and try the 3.0_beta image? I'm not sure why the table would be corrupted right after being created. Edit the container definition and change the Repository from uberchuckie/observium to uberchuckie/observium:3.0_beta. The image contains Observium 20.9, MariaDB 10.5.5 and a change to the run script to always update the file permissions.
  20. @seanwalter I've just pushed the tag for 3.0_beta. This includes Observium CE 20.9.10731, MariaDB 10.5.5 and the latest apt packages. It shouldn't change how the container works on your system but you can always give it a try. It works fine for me both creating a database from scratch and updating from the 19.8.1 schema.
  21. Another thing to look into is what Squid had mentioned. Do you have a cache drive? If so, is the volume mount on /mnt/user/appdata or /mnt/cache/appdata?
  22. @seanwalter MariaDB shouldn't be using /var/log/mysql for its log files or /var/lib/mysql for its data files. It's in the container's ephemeral disk and does not persist between container instances. It's supposed to use the /config/ volume mount. MariaDB is started with /usr/bin/mysqld_safe --skip-syslog --datadir='/config/databases' from the runit service, MariaDB should be using the volume mount for its data. It's weird that a brand new container instance works for you but not @chip. This has got to be something related to file permission issues or something along the line. It's hard for me to debug this without access to a broken system.
  23. @chip The "aria_log_control" should be created in the /config/database volume. /etc/service/mariadb/run is the runit script to start MariaDB in the container. It should be starting MariaDB with I'm not sure why it's using /var/lib/mysql in your case. EDIT: Ah, you were running it from the command line. Can you start from scratch and post up the error in the MariaDB log file? The log file should be '/config/databases/8ffb5f7097ea.err'
  24. @chip OK, I missed this earlier: 2020-09-23 15:28:02 0 [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied") 2020-09-23 15:28:02 0 [ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control' I'll take a look as to why it works on my server but not on yours.