I installed uptime-kuma using the VE helper-scripts. I found the network port in the json file in the repo it pulls from. Is there an easier way to find the port of a container running directly in proxmox. I tried pct info "containerid" and info is not an option for that command? Any help much appreciated. This info is not listed in the summary or network of the web ui on that container.
Container Port info
- Thread starter Reedler
- Start date
How should the host know, which port a certain Service inside a guest is listening on? The apps inside a vm or lxc can do nearly everything which would be possible on a native Linux, thus ProxmoxVE would need to do regular monitoring and Port Spannung outside and inside the container to have that information. That would be quite pointless since in any professional environment you would still have to setup your own monitoring thus it would be a waste of developer resources to reincent the wheel for the PVE dashboard.
Concerning your question:
You can probe for open ports outside the container with nmap container-ip or the netstat or ss command inside the container.
But in the end it's your job to set up the applications inside the container or vm which includes reading the docs of the Application.
https://github.com/louislam/uptime-kuma says it's on Port 3001.
Another thing: The helper scripts are not developed by Proxmox developers and hide a lot of complexity. If you are using them because you don't want to ve bothered with technial details and the Initial work of setup said complexity will bite back at some later time.
So please reconsider using them
Concerning your question:
You can probe for open ports outside the container with nmap container-ip or the netstat or ss command inside the container.
But in the end it's your job to set up the applications inside the container or vm which includes reading the docs of the Application.
https://github.com/louislam/uptime-kuma says it's on Port 3001.
Another thing: The helper scripts are not developed by Proxmox developers and hide a lot of complexity. If you are using them because you don't want to ve bothered with technial details and the Initial work of setup said complexity will bite back at some later time.
So please reconsider using them
Last edited:
Like I said I found the port in the helper script it deploys from. It would be nice if when you went into the summary of the container it showed some basic info about the container such as ports, network, volumes, etc. I realize folks use other tools for admin/monitoring etc. this but it would be nice add in my opinion. I get what you're saying but maybe the proxmox folks and the dev's on the helper scripts could work together. It would only benefit you both especially since Broadcom has ruined VMware.
The question is how would the hypervisor know what port your application is using. The hypervisor gives you a raw disk, a network port and a few CPU cores. You can run MS-DOS in a VM. You could run more than one application in an LXC container.
If you have a VM with Docker, then something like Rancher or Portainer has ‘templates’, but you may quickly outgrow them. You can get LXC containers from eg. TurnKey which the description will clearly tell you the port(s) for each application, but again, I find myself constrained in production using things like that.
If you have a VM with Docker, then something like Rancher or Portainer has ‘templates’, but you may quickly outgrow them. You can get LXC containers from eg. TurnKey which the description will clearly tell you the port(s) for each application, but again, I find myself constrained in production using things like that.
So ProxmoxVE should try to guess it or do a portscan itself because the person running the stuff doesn't want to setup a proper monitoring or read the documentation of their monitoring tool (uptime-karma in this case)? Even then it might miss something or report things wrong. This would be as useful as a coockie warning popup in the browser since soon users would ignore that information.
Well the community scripts are (Nomen est omen) a community project by volunteers mostly for homelabs, so I don't see what benefit they would have from investing time in UI development for Proxmox instead of developing further scripts for their community. Now Proxmox VE as a plattform definitively benefits from Broadcoms move but most companys considering a migration to ProxmoxVE have more issues with VmWare features PVE doesn't implement (yet). So I doubt that it would be a good business move to concentrate on features most of their paying customers are not interested in.
See also this discussion: https://forum.proxmox.com/threads/urgent-suggestion-tteck-scripts-for-proxmox.156821/
Now please don't get me wrong: I'm just a homelabber myself and not in any way associated with Proxmox Server Solutions. So this is just my personal opinion and in now way representative for the community here or the developers. But I know the discussions about VMWare Alternatives from my workplace. Our VMWare team doesn't care at all about the monitoring options or helper scripts for ProxmoxVE. TWhat matters for them is more stuff like Veaam support (which still seems to be quite buggy, to be fair this is nothing Proxmox developers can do much about it, Veeam needs to fix their stuff) or snapshot ability on enterprise storage arrays (which is also something which must be implemented by the storage vendor, so Proxmox developers can't do much expect improving their Storage plugin API).