Forums

rhessinger

Typically when you see an EPERM error that is caused by the OS. You can find quite a bit about it on Google and Stack Overflow. Typically users experience that issue on windows that have their drives indexed. Although, I want to believe that the npm client is your issue, I have a feeling that something is happening first and then the EPERM error is happening on the cleanup of the file. Especially since you are saying that npmjs.org does not have the problem. I noticed at the end of the error, it says "A complete log of the run exists at", would you be able to send that over to us?

If you don't feel comfortable attaching that to this post, you can send it to support@inedo.com and put [Support QA-609] in the subject. Just please let me know that you emailed it so I can keep an eye out for the email.

Thanks,
Rich

rhessinger

Hi @hwittenborn,

Could you please share a screenshot of what you are seeing? When I click on the package version, I see a Delete Package button when I hover over the Download Package multi-button. See below:

Thanks,
Rich

rhessinger

Hi @Fred and @hwittenborn,

You can actually configure docker to use insecure HTTP registries. As it states in our documentation, you can register a host and port as an insecure registry which will then tell your docker client to use HTTP instead of HTTPS. A good way to rule out the ProGet container would be to configure your Docker daemon to use insecure registries pointing to the HTTP port of your ProGet container and try to push it that way. For example:

If you have your ProGet container running HTTP on port 80 and host proget.domain.local, add this to your Docker daemon (or settings in Docker Desktop on Windows and Mac):

{
  "registry-mirrors": [],
  "insecure-registries": [
    "proget.domain.local:80"
  ],
  "debug": false,
  "experimental": false
}

Then if your repository name would be: proget.domain.local:80/my/imagename and your push command would look like:

docker push proget.domain.local:80/my/imagename:tagname

That will then push the image over HTTP vs HTTPS.

Is this only an issue in Visual Studio? Have you tried to push your image using the command line?

Thanks,
Rich

rhessinger

Hi @hwittenborn,

Thanks for the extra information. It is very much appreciated!

Are you saying the file fails to get added if you save it under the filename {feed-name}.pub?

I actually used it as a gpg file extension, but honestly, your solution much better. The file extension doesn't actually matter that much. Once it is added using apt-key, it just extract to contents and stores them in their keyring. You can see this by running sudo apt-key list.

I was more stating that in order for it to work for me on Ubuntu 20.04, I had to have everything named as the lowercase feed name in order for it to work for me. Although, I'm not sure if the lower case part matters. For example, for a feed name defaultdebian, I ran this:

wget -qO - http://proget.localhost/debian-feeds/defaultdebian.pub | sudo apt-key add -
echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/defaultdebian.list

sudo apt update

As a test I changed echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/defaultdebian.list to be echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/proget-defaultdebian.list and that actually wouldn't work for me. This caused a bunch of warnings when I ran sudo apt update. For some reason this only mattered in newer versions of apt though.

All in all, I will update the documentation to correct your command (adding the missing '-' ) and to include the updates to the naming. Hopefully, this will be clearer going forward for other users.

Thanks for all of your help!

Thanks,
Rich

rhessinger

Hi @hwittenborn,

I recently ran into similar problems in the latest version of apt on Ubuntu. This didn't actually seem to be an issue in the older versions of apt. I determined that naming is very important when using Debian and this is how I was able to get this to work:

wget -O "{feed-name}.gpg" http://{proget-server}/debian-feeds/{feed-name}.pub && sudo apt-key add "{feed-name}.gpg"
echo "deb http://{proget-server}/ {feed-name} {component-name}" | sudo tee /etc/apt/sources.list.d/{feed-name}.list

Basically, I had to add download the pub as a {feed-name}.gpg then add that key to apt. Then when registering it in the sources.list.d I had to name it {feed-name}.list. In my experience, if they are not all named the same way, when you try to run sudo apt update you will get a bunch of warnings and the packages will never actually show up as available to install.

I'm not sure if this is the same thing you were seeing, but I was waiting on a couple of customers to confirm that running the commands this way it all worked before updating the documentation.

My guess is that using wget -qO - http://{proget-server}/debian-feeds/{feed-name}.pub | sudo apt-key add -, it added the key with the name of {feed-name}.gpg or whatever extensions apt converts it to. When you ran echo "deb http://{proget-server}/ {feed-name} {component-name}" | sudo tee /etc/apt/sources.list.d/{proget-deb}.list what did your use of {proget-deb}.list? Was it your feed name?

Thanks,
Rich

rhessinger

Hi @Fred,

The message I'm pulling out of this error is The plain HTTP request was sent to HTTPS port. This indicates either the docker client is trying to push a non-SSL request to an SSL port (like HTTP://proget.com:443 where 443 is bound to SSL) or you have a bad forward of the host and port in your NGINX file. I recently did some testing on this and this was the NGINX file that I tested and worked: https://docs.inedo.com/docs/https-support-on-linux

Thanks,
Rich

rhessinger

Hi @hwittenborn,

Thanks for the additional information. We talked about this in our team meeting this week and we decided we are going to clean up when restarts are needed and we are hoping to give better messaging to the user when a container needs to be restarted. Some of the restart requirements are leftover from previous requirements that have since changed. So hopefully we can make this process a bit easier in the future.

Thanks,
Rich

rhessinger

Hi @hwittenborn,

I took a deeper look into this and it looks to work as expected. When it comes to Docker containers, we can't automatically restart the website like we can on Windows. So anytime that a setting is modified in the Advanced Settings or an extension is installed or removed, the docker container for ProGet will need to be restarted. In older versions of the image, we attempted to display a message to restart the container, but that implementation did not always work as designed so it was removed. I have forwarded this over to our products team to review any possible solutions that we could make in ProGet 6 to make this more obvious. I'm also working on ways to update our documentation to make this a bit clearer.

Thanks,
Rich

rhessinger

Hi @hwittenborn,

Let me do some testing on my side and I'll let you know what I find. What OS is your Docker engine running on?

Thanks,
Rich

rhessinger

Hi @hwittenborn,

Am I correct to say that the 502 errors are not with the NGINX proxy in front of it as well? Is this only when you are uninstalling the extensions? If not, what other settings are you changing when you see this issue?

Thanks,
Rich

rhessinger

Hi @Stephen-Schaff,

In newer versions of ProGet, we improved our performance by caching our user's privileges. This was especially necessary when using Active Directory based user directories. This can cause issues similar to this one where it can take some time before the privilege is updated. This is especially noticeable in ProGet HA clusters. The caching timeout is configurable in the Administration -> Advanced Settings by altering the Web.PrivilegeCacheExpiration value. By default, we set it to 30 minutes. There are areas that should refresh the cache on save, but those will only work in single instances of ProGet and I'm guessing it did not get triggered in this case.

Hope this helps!

Thanks,
Rich

rhessinger

Hi @Fred,

I think I may have found the issue. Can you include proxy_set_header Host $http_host; in your location node and see if that fixes your issue?

Thanks,
Rich

rhessinger

Hi @Fred,

It definitely can be settings in your Nginx settings, but nothing is jumping out at me. I am by no means an Nginx expert, but everything looks normal. I know we have quite a few users using Nginx with ProGet, so we know this is a working combination.

Just to get the easy Docker nuances out of the way first, I just want to verify that your certificate is not a self-signed certificate or generated by an internal certificate authority (there are things you need to set in the Docker client to get that to work). Also are you able to push images to ProGet using the command line? If not, are you able to send over the output of the CLI?

One other thing to try is to set the Web.BaseUrl in Administration -> Advanced Settings to your HTTPS URL (ex: https://proget.xxx.com).

Thanks,
Rich

rhessinger

Hi @Fred,

Does the HTTPS url (https://proget.xxx.com) work in your browser as well?

Thanks,
Rich

Posts made by rhessinger