Re: Errors Packaging Nebula
On 7 July 2021 1:48:01 pm IST, Alex David <flu0r1ne@flu0r1ne.net> wrote:
>
>On 7/4/21 3:34 PM, Nilesh Patra wrote:
>> I have something to ask here, before upload:
>>
>> You are installing the example config.yml into /etc right?
>>
>> I feel being an example file, it really should be installed as an
>example, i.e. d/example
>> Installing something in /etc/ would essentially mean that it is a
>"default" config file
>> - It does not look like a good default, since it seems to bind via
>ports, assumes users and groups, etc
>> - It also sources things from /etc/nebula/*.crt -- and these things
>will not be installed when installing the package
>> - Hence, the systemd service will fail at start unless user manually
>fixes all of it and starts the service
>>
>> Can you make a saner default (i.e. config.yml for nebula)?
>> If not, it might be better to remove this altogether and install as
>example instead, and leave the onus on user to set it up
>>
>> Or, you could write a maintainer script to ask these questions during
>installation and make a sane default config.yml
>
>Yes, most people start from that example script. From my understanding,
>there's no default combination of options that would prevent the
>service
>from failing; users need to generate key pairs to use Nebula. I think
>it
>would save users a lot of time to install a stub configuration file in
>/etc/nebula with a accompanying systemd file. That way, there's an easy
>and standard method to configure it. I could write a script if
>necessary
>but I don't feel like this would provide the best user experience since
>users would have to enter the paths to key files. This would be error
>prone and accomplished much better interactively.
>
>Here are the reasonable options as I see it:
>
>(1) Create a reasonable configuration file which lacks the key files.
>On
>installation, the user would be notified to generate the keys and move
>them into the proper directory. (With example commands to make it
>easy.)
>
>(2) Don't package a configuration file and notify the user to create
>it.
>
>(3) Just package the binaries.
>
>I personally like option (1) since it would require the least work on
>behalf of the user. (And this is how I'm guessing the vast majority of
>users scaffold it.) But, it would still fail if they started the unit
>before configuring Nebula. Let me know what you think.
Fair, option (1) looks like the most sensible thing to do. I agree
>> For this one, it looks like a fork of
>https://github.com/deathowl/go-metrics-prometheus
>> and the original repo looks more frequently updated. Would it not be
>possible to package the original and patch out the import paths?
>>
>> If not, will it not be possible to merge changes into the original
>repo?
>> IMO, packaging fork is suboptimal, unless the original one is
>abandoned and/or unmaintained and someone is willing to maintain fork
>long time
>> which doesn't seem to be the case here.
>
>You're correct: it's not ideal. The fork is maintained by the author of
>Nebula. There's an open pull that seems like it won't be resolved
>anytime soon. I messaged him asking about import path substitution.
>I'll
>let you know what I learn.
Cool!
>Would merging these changes into the
>upstream
>be a blocking requirement?
If the changes made by nebula author are really needed, then it makes sense to get it merged. Or you can do another thing which IMO would be better suited for the situation.
Package the original library, and not the fork. Now whatever changes are needed, just apply it as a debian patch. That way we don't need to wait for upstream to merge those changes. Ofcourse, this should be done if deemed appropriate, and it doesn't break anything.
I think applying needed changes as a patch should be fine anyway.
>> PS: Your email client seems to be appending a blank line after every
>line of reply you type,
>> and it's a bit annoying to quote long emails from you. Can you please
>fix this?
>> Also, do I need to reply to you and CC the list everytime, or are you
>already subscribed and I simply reply to the list?
>
>Okay, I'm a youngin' and didn't grow up with listservs and such :) Let
>me know if this email is formatted correctly.
Well, I'm only 21, and I didn't grow up with listservs either, haha. Yes, your email looks good now.
Nilesh
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: