Community Developer
  • Posts

  • Joined

  • Last visited

Everything posted by frakman1

  1. Thank you for the definitive answer and suggestion. I don't understand where the previous container's digest would be. Doesn't the old container get blown away after an upgrade? The only "inspect" I can run is on the new container. I also thought that an upgrade explicitly removed the orphan image that was the previous "latest" tagged image. I remember seeing that in the logs as the last step of the upgrade process. So after an upgrade, both the old container and the old image are gone and all I have is the new image and the new container created from it. Am I missing something? Maybe there's a misunderstanding. I'm not trying to figure out what version the current "latest" tag corresponds to. Yes, I can compare digests to published values. I am trying to determine the version of the previous version of the app just before the failed upgrade. It was also tagged as "latest".
  2. Unfortunately there is no way of knowing what the version I had running before the upgrade was. Was it the previous version? Was the it the one before that? etc. I don't upgrade as soon as a new release is made so it could be anything in the last year. Is there a log of the docker upgrade operations and associated output anywhere? @Squid It just seems wrong that if I didn't happen to take a screenshot of the docker upgrade popup then it's gone forever.
  3. I have a slightly different but related question. When I upgrade a docker app, there is a pop up with details about the upgrade. After the upgrade completes and I close that window and later find out that the upgrade failed, how do I know what the previous version of the docker image was? It's always set to xxx:latest in the template so there's no way of knowing after the operation completes what it was before. Is this information/log saved anywhere? When filing an issue/ticket against the app, I'd like to know what the source and destination versions where that caused the failure.
  4. Sorry, I misunderstood earlier. I didn't know there was a second 'official' app on Community Applications. I'll have to try is out and get back to you later. UPDATE: Sorry, it's highly unlikely that I will revisit this on a different version of the app. It seems it was added after I started using the one from Grack's Repository. I updated my post to show which version I am using. You can use that one if you like.
  5. I am using this docker jlesage/nginx-proxy-manager If you're talking about jc21/nginx-proxy-manager:latest Then its /etc/nginx/nginx.conf configuration has this line: access_log /data/logs/fallback_access.log proxy; Which mean you will need to map the /data/logs folder to a location that the goaccess container can also access. You will also need to change the goaccess configuration to look for that log file instead of the one currently configured
  6. You do that by editing the docker template page. Goto the DOCKER tab, click on Gitlab-CE and select "Edit" Locate the field labeled Repository. It should be set to gitlab/gitlab-ce:latest This is what controls what version of Gitlab-CE you are using. A quick breakdown of the components of this string is: gitlab: user on dockerhub gitlab-ce: name of the repository latest: version To change it to something else, first find out what the official tags are from the dockerhub page for that project here. Click on the Tags tab and search for the version that you want. For example, 13.9.2, would correspond to 13.9.2-ce.0 Now enter that version instead of latest in the Repository field of the Gitlab-CE docker template: Repository: gitlab/gitlab-ce:13.9.2-ce.0 Hope that helps!
  7. I address this point in Step One of my post. The idea is not to have to change anything in nginx.conf and map the folders appropriately.
  8. Can you please share your private repo so I can try the tftp app? I tried to PM but it didn't work
  9. You can do that by modifying the repository that the docker template is using. It looks like it is currently using the "master" tag: To change it, head out to where it is hosted on docker hub: and pick the tag that you want and replace it. Example: mattermost/mattermost-team-edition:5.33.4-rc1
  10. I'm not 100% sure what the original state of the "Use SSL/TLS" setting was but I think it was originally No and that installing the plugin enabled it. If I'm wrong and it was set to Yes already, then removing the plugin should remove the new certificate so that it would continue using the self-signed hostname certificate.
  11. Thank you. I tried that solution but that wasn't satisfactory either. It was still using the new Unraid certificate. Uninstalling the plugin should really remove everything that it added.
  12. For those suffering from the recent error: Error: ER_WRONG_NAME_FOR_INDEX: Incorrect index name 'migrations_lock_lock_key_unique' I was able to recover by droping the two tables migrations and migrations_lock tables as mentioned in the ghost user forum I used the adminer docker that lets you do it easily via a web UI.
  13. I decided to uninstall this plugin. However, now anytime I go to tower.local or the IP addres, it always redirects to the URL which requires a functioning internet and DNS which isn't always true when I reboot the server. This seems like a bug. When I uninstall this plugin and reboot the server, I don't expect any remnants of the to exist. How do I completely remove this redirection and go back to using my IP address directly? Update, well I looked at the /etc/nginx/conf.d/emhttp-servers.conf file and found the offending line here: server { # # Redirect http requests to https # listen *:80 default_server; listen [::]:80 default_server; return 302$request_uri; } However commenting it out just breaks the webUI and reverting the whole file to a backup and rebooting results in it being regenerated again. I can't find where to turn it off. I've already uninstalled the plugin so I can't go into any settings and turn things off. I even tried re-installing the plugin, turning off the remote access etc and then uninstalling but still have the same problem. Also, it is still using the WebUI SSL certificate that it installed for use with the plugin. How do I remove that too? I just want it to go back to the way it was without any of the stuff. I was able to locate the certificate here: /boot/config/ssl/certs/certificate_bundle.pem and the original one is in the same folder here: /boot/config/ssl/certs/Tower_unraid_bundle.pem but not sure what to do with them. _____________________________ Final Update -> Solved Under Settings -> Management Access -> Use SSL/TLS. When I hit the ? symbol, I saw this useful help page: The path is actually /boot/config/ssl/certs. In there I found the offending certificate, certificate_bundle.pem. I moved it somewhere else for safekeeping and rebooted the server and then it finally went back to normal. 🔍 Mystery solved.
  14. When adding Code block into a post, there are several language options but not the one I use the most, Bash. Please add a Bash Syntax Highlighting option in the Code Block popup. Thank you
  15. The "drvload" command should be run within the "Command Prompt" box, so it is surprising to me that anything would hang since it's not a full-blown windows environment. I don't really know but if it's hanging after loading the virtio driver, then take a look at which iso you are using. I'm using this one: Maybe you could try different ones.
  16. @NanoI just made a quick guide. Hope that helps.
  17. Pre-requisites - You have Nginx Proxy Manager already installed and working. I am using this one from the Community Applications: jlesage/nginx-proxy-manager: - You have installed goaccess from Community Applications but it's not working out-of-the-box. I am using this one from the Community Applications: gregyankovoy/goaccess There are three main steps 1- Have your log generator container (Nginx Proxy Manager) output its logs into a folder that goaccess can, well, access 2- Configure goaccess to look for the right log file 3- Configure goaccess to understand how to parse the log/date/time format Step One: Map Log File Folder I use Nginx Proxy Manager and by default, it puts its access logs in the file /config/log/default.log. This location is non-configurable. Well, actually it's configured in the file /etc/nginx/nginx.conf with the line: access_log /config/log/default.log proxy; ... but nginx.conf is not in a mapped folder so I just left it alone. I just ensured that it mapped its /config/log folder to a folder that both containers could access. In my case, I used /mnt/user/dmz/goaccess/log Step Two: Configure Log File The goaccess container looks for its access logs in the file /opt/log/access.log by default. Luckily, this is configurable in the goaccess.conf file that is mapped to the host's /mnt/user/appdata/goaccess/goaccess.conf file. In there, change the line: log-file /opt/log/access.log To: log-file /opt/log/default.log Step Three: Configure Log Format The other thing to do is to provide the log/date/time file format that Nginx Proxy Manager uses in a language that goaccess understands. The nginx format is defined in the same nginx.conf file mentioned above as: log_format standard '[$time_local] $status - $request_method $scheme $host "$request_uri" [Client $remote_addr] [Length $body_bytes_sent] [Gzip $gzip_ratio] "$http_user_agent" "$http_referer"'; There is a nifty script that does this mapping for you here. The short story is that it has to look like this for goaccess to understand it otherwise you get parsing errors. time-format %T date-format %d/%b/%Y log_format [%d:%t %^] %s - %m %^ %v "%U" [Client %h] [Length %b] [Gzip %^] "%u" "%R" Now, open the file goaccess.conf again and comment out the line: log-format COMBINED and paste the three lines describing the log/date/time format we want. That's it. You should now have a beautiful dashboard of your Nginx Proxy Manager access logs including which subdomains are getting used most (virtual hosts) and which URLs end up going to 404 (possible attacks) and a whole lot more besides! Sample Dashboard: Note that it should update in real time as long as the settings cog on the left has a green dot near it like this: That means that the websocket is connected. BONUS If you want to get all geeky and see the results in a terminal window, you can do that too. Just open the goaccess container's Console window and paste the three lines of log/date/time format into the file ~/.goaccessrc so it looks like this: # cat ~/.goaccessrc time-format %T date-format %d/%b/%Y log_format [%d:%t %^] %s - %m %^ %v "%U" [Client %h] [Length %b] [Gzip %^] "%u" "%R" and run: goaccess /opt/log/default.log And you will get the same information in a terminal window: (Navigate with TAB and SHIFT+TAB button to jump between sections and ENTER to expand selection. q to quit)
  18. You would need to put your public key in: /root/.ssh/authorized_keys However, in order to survive a reboot, you'll have to put it in the USB flash drive too. That location is: /boot/config/ssh/authorized_keys Note that if you do this, you won't be able to use Virt Manager because that requires a username/password to login with.
  19. Pardon the stupid question but isn't that everything that matters though? I thought those are the main Unraid folders that you'd want it to run on. What is it for if not that?
  20. @jowi How do I get pip (for python 2.7.10) to work on Unraid? I have Nerd Pack and Dev Pack installed. I have version 2.7.10 of Python. When I run the above command, I get: # python -m ensurepip --default-pip ERROR:root:code for hash md5 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type md5 ERROR:root:code for hash sha1 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha1 ERROR:root:code for hash sha224 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha224 ERROR:root:code for hash sha256 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha256 ERROR:root:code for hash sha384 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha384 ERROR:root:code for hash sha512 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha512 Ignoring ensurepip failure: pip 6.1.1 requires SSL/TLS
  21. There are many plugins that add to the Dashboard. The Plex Streams plugin is just one example. It has it's own Tab as well as a Dashboard widget Are you saying that you can't add to the UD widget in the Dashboard or that you don't want to (which is fine if that's the case)?
  22. A reboot seems to heal things for now. I can see the Unassigned devices listed under Main now. Another question about the plugin: How come the Utilization bar is not populated in the Dashboard but is populated in the Main tab? Dashboard: Main:
  23. My server is acting weird. Super high average load values even after stopping all VMs and docker. It may or not be related. There are a ton of hdparm calls in the D (uninterruptible sleep) state. I don't know if that's a plugin or OS thing I posted a thread about it here:
  24. I stopped all my VMs and docker containers but it's still inthe same state. I looked at htop again and it's full of calls to hdparm that are in the D (uninterruptble sleep) state.