Bug 1330393 - Default docker-distribution.service file doesn't work as lack of subcommand
Summary: Default docker-distribution.service file doesn't work as lack of subcommand
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker-distribution
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Lokesh Mandvekar
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-26 06:52 UTC by Luwen Su
Modified: 2016-05-12 14:52 UTC (History)
0 users

Fixed In Version: docker-distribution-2.4.0-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-12 14:52:34 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1058 0 normal SHIPPED_LIVE docker-distribution bug fix and enhancement update 2016-05-12 18:51:06 UTC

Description Luwen Su 2016-04-26 06:52:44 UTC
Description of problem:
docker-distribution change the way it start, but the .service file not


Version-Release number of selected component (if applicable):
docker-distribution-2.4.0-1.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1.
#systemctl start  docker-distribution.service
registry[6762]: Error: unknown command "/etc/docker-distribution/registry/config.yml"

[Service]
Type=simple
ExecStart=/usr/bin/registry /etc/docker-distribution/registry/config.yml


2.
This should work:
#registry serve /etc/docker-distribution/registry/config.yml

WARN[0000] No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable.  go.version=go1.4.2 instance.id=ff1e201e-3ec1-40ba-a4e4-fc35aee2f0bc version=v2.4.0+unknown
INFO[0000] redis not configured                          go.version=go1.4.2 instance.id=ff1e201e-3ec1-40ba-a4e4-fc35aee2f0bc version=v2.4.0+unknown
INFO[0000] using inmemory blob descriptor cache          go.version=go1.4.2 instance.id=ff1e201e-3ec1-40ba-a4e4-fc35aee2f0bc version=v2.4.0+unknown
INFO[0000] listening on [::]:5000                        go.version=go1.4.2 instance.id=ff1e201e-3ec1-40ba-a4e4-fc35aee2f0bc version=v2.4.0+unknown
INFO[0000] Starting upload purge in 8m0s                 go.version=go1.4.2 instance.id=ff1e201e-3ec1-40ba-a4e4-fc35aee2f0bc version=v2.4.0+unknown


Additional info:
The default service should start correctly.

Comment 2 Lokesh Mandvekar 2016-04-28 19:31:04 UTC
thanks, I'll update!

Comment 3 Luwen Su 2016-05-02 08:56:18 UTC
Verified in docker-distribution-2.4.0-2.el7.x86_64.

Fill in a full testing steps for reference:
1.The registry can start by default config
install docker-distribution and start the service
#service docker-distribution start

2.Configuration config.yml with enabling tls function:
#cat /etc/docker-distribution/registry/config.yml 
version: 0.1
log:
  fields:
    service: registry
storage:
    cache:
        blobdescriptor: inmemory
    filesystem:
        rootdirectory: /var/lib/registry
http:
    addr: :5000
    headers:
        X-Content-Type-Options: [nosniff]
    tls:
        certificate: /root/certs/domain.crt
        key: /root/certs/domain.key

health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3

Make self-signed ca and crt:
#mkdir -p certs && openssl req  -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key  -x509 -days 365 -out certs/domain.crt

#mkdir -p /etc/docker/certs/myregistrydomain.com:5000/
#cp certs/domain.crt /etc/docker/certs/myregistrydomain.com:5000/ca.crt

Start docker-distribution and docker service.
Then a martix pull and push testing covered.
* 1.10 docker(docker-latest) pull and push
* 1.9 docker pull and push
* HostA:1.10 docker push, HostB: 1.9 docker pull and vice verse. 

Move to verified

Comment 5 errata-xmlrpc 2016-05-12 14:52:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-1058.html


Note You need to log in before you can comment on or make changes to this bug.