New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rsync in sshd package #3278

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@errordeveloper
Copy link
Contributor

errordeveloper commented Jan 27, 2019

The rsync command has to be available on both ends.

@GordonTheTurtle

This comment has been minimized.

Copy link
Collaborator

GordonTheTurtle commented Jan 27, 2019

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "sshd-rsync" git@github.com:errordeveloper/linuxkit.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Add rsync in sshd package
Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com>

@errordeveloper errordeveloper force-pushed the errordeveloper:sshd-rsync branch from 9049864 to c791883 Jan 27, 2019

@GordonTheTurtle GordonTheTurtle removed the dco/no label Jan 27, 2019

@errordeveloper

This comment has been minimized.

Copy link
Contributor Author

errordeveloper commented Jan 28, 2019

I am not sure why CI gives me this error:

Failed to create OCI spec for linuxkit/sshd:a0ac44ab1cbfd14e368ed139c6a4e128f2a33513: Trusted pull for linuxkit/sshd:a0ac44ab1cbfd14e368ed139c6a4e128f2a33513 failed: No valid trust data for a0ac44ab1cbfd14e368ed139c6a4e128f2a33513

From previous experience, I recalled that I need to bump all uses of a package in the same PR/commit that introduces the changes to the package itself - does CI now assume that changes are made separately?

@ijc

This comment has been minimized.

Copy link
Collaborator

ijc commented Jan 28, 2019

I'm not sure we want the sshd base layer to be the union of anything anyone might ever want in that context. e.g. we currently IIRC don't include the packages necessary to make scp "just work" (or perhaps I'm thinking of sftp, either way).

I'd suggest that either you can apk add -U rsync on the fly, or your can use FROM to build a derivative image for your use case.

@deitch

This comment has been minimized.

Copy link
Collaborator

deitch commented Jan 28, 2019

I'm not sure we want the sshd base layer to be the union of anything anyone might ever want in that context. e.g. we currently IIRC don't include the packages necessary to make scp "just work" (or perhaps I'm thinking of sftp, either way).

Tough call. I tend to agree with this sentiment, but then why do we have the wireguard package installed (see here)?

I think this might be easier if there were a simple way for a consumer of lkt to just use the standard linuxkit/sshd package, but yet have the desired tools made available without having to extend the base. Mounted in? Standardly available dir? Unlike most pkg/ parts, sshd (it keeps auto-correcting to sushi) is a CLI, so people will want things in there that they find useful, and so we are likely to get more and more of these, and more and more discussion of what is "standard" and "base" and "commonly used". We definitely have an answer with "extend it in a Dockerfile with what you want," but I am wondering if we could have an easier one?

@errordeveloper

This comment has been minimized.

Copy link
Contributor Author

errordeveloper commented Jan 28, 2019

Tough call. I tend to agree with this sentiment, but then why do we have the wireguard package installed (see here)?

Yes, inderd. I had second thoughts, but after finding wireguard, I figured rsync might be reasonable to add.

@deitch

This comment has been minimized.

Copy link
Collaborator

deitch commented Jan 28, 2019

I just looked at the history; wireguard has been in since July 2017, when it was added to everything else. I don't recall the PR that added it, or the discussions around it, offhand. I do recall other discussions around adding more "standard" packages to getty and sshd, and usually they were held back to keep it minimal.

I would like to see none of it in there, and one of:

  • a way to mount in desired apk packages (or binaries) from another location, so they can be kept clean
  • a way to add them in "on the fly", i.e. during lkt build

Either of these essentially comes down to some higher-order form of composition. We already have composition of layers and packages via Dockerfile to build OCI images, and we have composition of those images using a linuxkit.yml to build OS images via lkt build. There is some middle layer here, where lkt can know to do some additional composition.

I am just not sure what that is, and if it is worth it...

@errordeveloper

This comment has been minimized.

Copy link
Contributor Author

errordeveloper commented Jan 28, 2019

Making it easier to fork a package without copying much of the config would be great. For example, sshd package has many binds, and wouldn't want to make a copy of those, I would rather add one or two on top. Perhaps we could add 'from' field in pkg config?

@deitch

This comment has been minimized.

Copy link
Collaborator

deitch commented Jan 28, 2019

We have spoken in the past about some of the issues with appending to binds rather than overriding. Lots to do here for configurability...

@rn

This comment has been minimized.

Copy link
Member

rn commented Jan 28, 2019

I'm with @ijc on leaning towards not adding rsync to the sshd package. It seems a bit niche.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment