The apt package is build against libssl1.0 which is not available on Debian Stretch giving the following error:
libssl.so.1.0.0: cannot open shared object file: No such file or directory
Install Method: apt-get
CLI Version:
azure-cli (2.0.9)
acr (2.0.7)
acs (2.0.9)
appservice (0.1.9)
batch (3.0.2)
billing (0.1.2)
cdn (0.0.5)
cloud (2.0.5)
cognitiveservices (0.1.5)
command-modules-nspkg (2.0.0)
component (2.0.6)
configure (2.0.9)
consumption (0.1.2)
core (2.0.10)
cosmosdb (0.1.9)
dla (0.0.9)
dls (0.0.9)
feedback (2.0.5)
find (0.2.5)
interactive (0.3.5)
iot (0.1.8)
keyvault (2.0.7)
lab (0.0.7)
monitor (0.0.7)
network (2.0.9)
nspkg (3.0.0)
profile (2.0.7)
rdbms (0.0.4)
redis (0.2.6)
resource (2.0.9)
role (2.0.7)
sf (1.0.4)
sql (2.0.6)
storage (2.0.9)
vm (2.0.9)
Python (Linux) 3.6.1 (default, Jun 22 2017, 12:11:55)
[GCC 4.8.4]
Python location '/opt/az/bin/python3'
OS Version:
Debian Stretch
Shell Type:
bash
Thanks for reporting. We'll look into this.
Keep in mind that oldstable (jessie) does not have libssl1.1, but libssl1.0.0. So you need to introduce another distribution alongside wheezy.
Wouldn't it be vastly preferable if you just didn't bundle an entire copy of python3 in the package and just had a dependency on the distribution python packages you needed? Embedding copies of system packages in your package is always going to be fragile this way and also have tons of security issues.
For now users can install the libssl1.0.0 from jessie-backports from here:
https://packages.debian.org/jessie-backports/amd64/libssl1.0.0/download
Installing libssl1.0.0 from jessie-backports causes issues then with .net core 2.0 cli
Is there a workaround as right now it seems that one cannot install a specific azure cli version using a Dockerfile for stretch which you also want .net core 2.0 cli installed on.
@derekbekoe
With a nod to @derekbekoe who has commented on this extensively this is my snippet of Dockerfile, incidentally it's for a jdk:8 base I use for Teamcity build agents so I can automate code and infrastructure in one pane of glass.
The apt-get just caused opensll issues that clashed with the .Net core cli.
The manual method requires /dev/tty so this is really the only way that has minimum issues.
# Azure CLI Version 2
# Specify requirements explicitly
#
# To get requirements for a specific version:
#
# docker run -it azuresdk/azure-cli-python:2.0.23
# pip freeze > requirements.txt
#
COPY requirements.txt /tmp/requirements.txt
RUN pip install -r /tmp/requirements.txt
Closing as this is due to https://github.com/Azure/azure-cli/issues/3720.
Will keep conversation in that single issue.
Most helpful comment
Wouldn't it be vastly preferable if you just didn't bundle an entire copy of python3 in the package and just had a dependency on the distribution python packages you needed? Embedding copies of system packages in your package is always going to be fragile this way and also have tons of security issues.