New packaging

[babolivier]

As discussed in #11

• [x] Create a package containing only the dependencies (cozy-deps)
• [x] Document the installation procedure in the Arch Wiki (ArchWiki:Cozy)
• [x] Update the official Cozy documentation
• [ ] Update the GitHub repo

[ArchangeGabriel]

I suggest you to edit this Caddy example. I don’t use it, so can’t fix it, but that’s definitively your IP in there.

[babolivier]

Oops, indeed haha. Fixed, thanks for the ping!

[ArchangeGabriel]

Regarding the package, I would suggest to add the systemd unit in it.

Regarding dependencies ca-certificates, bash, curl, openssl and sqlite are all in pacman tree, and probably in a number of dependencies of others cozy dependencies. So, I’m not sure it’s really pertinent to include them either in the wiki or the PKGBUILD.

You write “Both procedures will install Node.js version 6.x or 7.x.”, but the PKGBUILD install 4.x, right?

About weboob, does Cozy manage its own version now? Before Kresus used to, but then they went to system one, so I’ve created weboob-headless for that, but the systemd unit you provide seems to indicate Cozy now handles it for Kresus? Is system one still usable? If so, I would recommend going this way and add weboob to the optdepends (eventually pointing to weboob-headless in the description).

What happen if you do not configure a background?

[ArchangeGabriel]

Regarding official Cozy documentation, I suggest pointing to the ArchWiki. Avoid duplication efforts. ;)

[ArchangeGabriel]

Maybe add a link to this repo from the wiki page to say that bugreport regarding Cozy on ArchLinux specifically should be reported here?

[ArchangeGabriel]

Finally, they are probably a lot of internal links to be made (like pointing to pages about SSL certificate creation when needed), but that can wait.

[babolivier]

Regarding dependencies ca-certificates, bash, curl, openssl and sqlite are all in pacman tree, and probably in a number of dependencies of others cozy dependencies. So, I’m not sure it’s really pertinent to include them either in the wiki or the PKGBUILD.

Bash has been removed from the PKGBUILD. Not the wiki, my mistake, doing it right now. Regarding the others, I consider that all packages that aren't part of the base or the base-devel group belong in the dependencies.

Regarding official Cozy documentation, I suggest pointing to the ArchWiki. Avoid duplication efforts. ;)

https://github.com/cozy/cozy-docs/pull/329 :smile:

Maybe add a link to this repo from the wiki page to say that bugreport regarding Cozy on ArchLinux specifically should be reported here?

That's something I was wondering while writing the page. In my opinion, such links don't belong in this kind of wiki pages, but I can be wrong.

Finally, they are probably a lot of internal links to be made (like pointing to pages about SSL certificate creation when needed), but that can wait.

Absolutely, there's still quite a lot to do. My goal, here, was to provide a minimal documentation, enough to install Cozy with some skills in non-specific part (like the SSL certificate creation), that can be extended afterwards, by either me or other contributors.

[ArchangeGabriel]

Regarding deps, after cozy to cozy-deps switching, this are said not to be needed: cozy-management pngcrush pwgen python2-virtualenv supervisor.

OK for pwgen, OK for supervisor, but regarding python2-virtualenv, cozy-management and eventually pngcrush, I’m definitively not sure.

[ArchangeGabriel]

(Well, cozy-management isn’t strictly needed, maybe could be added as optdepend?)

[ArchangeGabriel]

I’ve made a new package: https://aur.archlinux.org/packages/cozy/. I’ll update the doc. This is not very important since the V3 is coming anyway, but might still be useful for some in the meantime.

[babolivier]

Nice work @ArchangeGabriel!

If I understood correctly, you leave the CouchDB configuration and Cozy's configuration (domain/background) to the user and will document it in the Wiki once you've updated it, right?

[ArchangeGabriel]

Exactly. Only remaining steps are creating cozy-data-system and cozy-home users, generating the tokens and giving them the right permissions, setting up CouchDB and install the stack.

Creating users and generating tokens could be done in the package, but I felt it would be better to leave it to the users, because they’ll have work to do anyway and this makes things simpler on the packaging side.

[babolivier]

Agreed. Plus, it gives them more insight on which users are created (imho it's better for users to know explicitely what users are created (even more considering Cozy actually creates one user per app) than having a script doing all of it magically, especially in the context of running Archlinux).

[ArchangeGabriel]

Indeed, actually we wouldn’t even need to create the users manually if we had not files to make them own.

Plus I’m not sure how the V3 stands here, but I guess this one user per app thing might be a bit different.

[ArchangeGabriel]

One thing that might need improvement still (but maybe not needed for V3, depending on my previous point) is being able to run cozy-controller as cozy user instead of root. But I’m not sure how much config this is, since I guess they are a lot of operations that require root privileges (like that starting other apps with their own users).

[babolivier]

Indeed, actually we wouldn’t even need to create the users manually if we had not files to make them own.

In v2, each app is a Node.js process on the host (except for the serverless apps which are ran by the proxy), so we still need an user per app.

Plus I’m not sure how the V3 stands here, but I guess this one user per app thing might be a bit different.

As v3 is right now, only serverless apps are supported, so this thing won't be relevant in the near future. However, this won't last forever, as it's only a temporary measure to let the dev team come up with a way to isolate each app from each other in a clean and efficient way.

One thing that might need improvement still (but maybe not needed for V3, depending on my previous point) is being able to run cozy-controller as cozy user instead of root. But I’m not sure how much config this is, since I guess they are a lot of operations that require root privileges (like that starting other apps with their own users).

Yep, this one will be hard to run with no root access. However, IIRC, it's only needed for v2, so it's only a matter of time before it becomes obsolete.

[ArchangeGabriel]

I’ve now updated the wiki page. ;)

Regarding v3, I’ll wait for an official documentation regarding self-hosting. Especially, we might need to document all the required certs name, and the reverse proxying config should change a bit.

[babolivier]

I’ve now updated the wiki page. ;)

Awesome, thanks again!

Regarding v3, I’ll wait for an official documentation regarding self-hosting. Especially, we might need to document all the required certs name, and the reverse proxying config should change a bit.

Indeed. However, v3 is currently in early alpha so it'll take some time before it's ready for packaging 😄

[ArchangeGabriel]

Well the v3 that is advertised lastly comes with “beta” as qualification. ;p And at the June, 1st meetup they were talking of September for self-hosting documentation. So not that far away. ;)

[ArchangeGabriel]

Just to let you know, I’m already working on the packaging of the v3, it will be available as cozy-git in AUR soon.

[babolivier]

Awesome! Thanks again for your work :)