Conversation
SuperSandro2000
left a comment
There was a problem hiding this comment.
We cannot use freeform settings here?
There was a problem hiding this comment.
We should probably build a python env with the modules
There was a problem hiding this comment.
Why? This pattern is widely used in nixpkgs: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+"++python3.pkgs."&type=code
These only used during the build, not in runtime.
There was a problem hiding this comment.
Please be a bit more specific than everything. Also we normally place postPatch right after patches and src
There was a problem hiding this comment.
Don't we want to take ca-certs?
There was a problem hiding this comment.
WDYM? These self-signed certificates are provided for testing purposes.
In NixOS module, they're enabled by default unless overridden by the user.
There was a problem hiding this comment.
Enabled by default in the updated commit.
|
About configuration: can we just keep the defaults for most stuff, then edit whatever overrides in? And probably it would be done NixOS/rfcs#42 style with only a few options defined explicitly but whatever the user puts deep into the structure being used for overrides, too… |
|
Also silly question: is it a good idea to add the package first and discuss the configuration generation in a follow-up? |
Atemu
left a comment
There was a problem hiding this comment.
The package diff LGTM apart from a few smaller things.
The module though... It's a beast. I don't think it's reasonable to accept such a huge module.
- Would it be possible to only pass a subset of options and have the application use the upstream default values on its own?
- If that is possible, would it be possible to make this a RFC42-style
settingsoption so that we don't have to declare any options ourselves? - In the docker image, the app takes a few env vars to configure the most important things. Perhaps we could limit the module to those (via RFC42-style env var option) and then give the user the ability to pass a plain config file text. This would significantly slim the module while still providing useful high-level options to the user.
There was a problem hiding this comment.
Honestly, at that length of the pattern (spurious hits are not too likely) I'd say either way is fine (LibreOffice packaging uses a mix, because long substitutions are easier to maintain than patches)
There was a problem hiding this comment.
Removed the first change as it's not required if mount_namespaces enabled. (enabled in the NixOS module by default)
Moved the second change to ./fix-file-server-regex.patch.
33ce05d to
91a524a
Compare
|
Update:
I've considered the following alternative freeform approaches:
|
This should probably be reported upstream, even if you already implemented a workaround. |
There was a problem hiding this comment.
I'm assuming this should be:
| in `coolwsd.xml`, or `--o:net.post_allow.host[0]='127\.0\.0\.1 --o:net.post_allow.host=::1` in | |
| in `coolwsd.xml`, or `--o:net.post_allow.host[0]='127\.0\.0\.1 --o:net.post_allow.host[1]=::1` in |
There was a problem hiding this comment.
| package = lib.mkPackageOption pkgs "collabora-online" { }; | |
| package = lib.mkPackageOption pkgs "Collaborate Online" { default = "collabora-online"; }; |
(!!) yes, please report this, thanks! |
Reported upsteam: CollaboraOnline/online#10049. |
|
@xzfc , thank you for implementing this. I tried to use the alias groups, but it did not work. I just wanted to know if it worked for you. Since from the docs these environment vars should only work for the docker image. https://sdk.collaboraonline.com/docs/installation/CODE_Docker_image.html?highlight=aliasgroup1 Instead I think this part should actually be filled in: Could you let me know if you are certain the alias groups work in your config, If not I'll likely start drawing up a PR to fill in the config file. 🙂 |
@beardhatcode - The docs are correct in that for regular manual installations of Collabora Online the alias groups would not work ... however that's controlled by the Relevant PRs are maybe https://github.com/CollaboraOnline/online/pull/7160/files and CollaboraOnline/online#10379 |
Description of changes
URL: https://www.collaboraonline.com
This PR adds Collabora Online Development Edition (CODE). CODE is a way to run LibreOffice in the browser. Continuation of #329525.
In this PR two things are introduced:
collabora-online.cc: @7c6f434c
fixes #333457
How to run
This guide will let you run a NixOS VM with Collabora Online and Nextcloud. The purpose is to provide a quick start and to demonstrate that it works, so it's messy and insecure.
Note: I am still yet to figure out how to properly run host-accessible NixOS VMs1, and not port-forwarded ones. That's why the hostname of the host and the VM should match.
Build VM
Grab this definition of NixOS VM and replace
myawesomehostnamewith the hostname of your host. (the VM and the host should have the same hostname)vm.nixBuild it with the following command:
nix-build \ -I nixpkgs=/path/to/nixpkgs \ "<nixpkgs/nixos/modules/installer/tools/nixos-build-vms/build-vms.nix>" \ --argstr networkExpr "$PWD/vm.nix"Run VM
Sudo is required to bind the VM to port 80.
Login
In a browser, go to
http://myawesomehostname.It will prompt you with a login page. Enter
rootanda.Create a new document
In the top left corner select "Files", then "+ New", then "New Document". Press "Create".
Click on the newly created document to open it.
The Collabora Online editor should appear.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.
Footnotes
They should use qemu's
-net tap, I guess. ↩