@emer-connelly_2117 very cool, thanks for sharing!!

@atripp Good to know Thanks

Hi @atripp Thanks for the tips. Best regards Philippe

Hi @atripp, Thanks for the response! It turns out I was overlooking the fact that the docker container cannot access the files of the host. So the directory was non-existent from the perspective of the ProGet instance. I ended up solving the issue by copying my bulk import directory into the docker container itself, which allowed the bulk import service to detect the directory.

@rhessinger said in buildmaster linux docker install: sa login failures: @mcascone slope game said in buildmaster linux docker install: sa login failures: docker exec -it inedo-sql /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P 'redacted' -Q 'CREATE DATABASE [ProGet] COLLATE SQL_Latin1_General_CP1_CI_AS' Hi @mcascone, This line has the issue. You created a database named [ProGet] instead of a database name [BuildMaster] as you stated in the connection string on the third command. Thanks, Rich Thank you very much for the explanation. It works now.

Hello Mickael, ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address. Here's the documentation for setting up SSL Traefik and nginx: https://docs.traefik.io/user-guide/examples/#http-https-with-sni https://nginx.org/en/docs/http/configuring_https_servers.html

I took a while to get back to this thread, but here goes: Today we upgraded to the MSSQL backed version of ProGet, that is currently on the Docker hub (5.2.9.11), and most of it went smooth. However, when restoring all the packages, I did get the unresponsive errors again. But this time the server came back and we could see the log messages. After changing the connection string, things seem to be more stable now when doing a full restore. The new connection string has this appended to it: "Max Pool Size=200;" Hopefully this version keeps us happier, as the old version needs a reboot every other day.

This is also being discussed here; long story short, this is a bug in Microsoft's PowerShell Gallery (and in the packages) in that they have two conflicting version numbers, and sometimes one is used, sometimes the other is used. The docs have been updated for now: https://github.com/Inedo/inedo-docs/commit/10c42c3ad546ac2feb4748b7736db06567c7a6d6

Thanks it works. I can then continue my testing and integration. With kind regards.

Both of these package types will be supported in 5.2. PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

In the post you linked, the problem was the host operating system (Ubuntu 14.04). So you should upgrade to 16.04.2 LTS. If it's not working, then you'll likely need to explore the docker script, and step into the container to see what specifically is the issue.

Hello Javier, There is an error in the PostgreSQL version of NuGetPackagesV2_GetLatestStable, which was introduced in the 5.0 beta. I've filed this as PG-1164 and submitted a fix for my co-workers to review.

Copying the explanation from the private ticket in case anyone else has this issue: Inedo products store timestamps in the database as UTC, but our PostgreSQL library (Npgsql) "helpfully" converts DateTime objects to the local time zone. They added a way to change this behavior in their 3.3 release, but the currently available version of Npgsql is 3.2.5. I've written a workaround for this, where DateTime objects will be converted to UTC by the database middleware. I've filed this as ILIB-7.

When this build finishes, docker pull inedo/proget will fix the issue with special characters in the database password: https://hub.docker.com/r/inedo/proget/builds/bi8ds7thvriyfldkbh2daj6/

Issue was due to the noexec option on the /tmp partition. Remove the noexec option and remount the /tmp.

Hi Ken, Thanks for contacting us. We are aware of this issue and have traced it to be a bug in a database script, that only affects Linux. The good news is we already have issued a fix for the problem (https://inedo.myjetbrains.com/youtrack/issue/PG-1101), it just needs to be reviewed and tested.

Looks like these symptoms are caused when the host goes OOM

Thanks for the quick reply! Ok, that's a shame but understood.

Thanks for the response! Gotta say, I'm impressed that y'all take the time to answer questions like this, even when they're from free-license users.