public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: sslh (and some general AddOn questions)
Date: Fri, 15 Jan 2021 13:43:40 +0100	[thread overview]
Message-ID: <01c25fd8-7fd8-9d2e-c445-92fcc89bafe0@ipfire.org> (raw)
In-Reply-To: <20210115113545.GA2763257@vesikko.tarvainen.info>

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

Hi Tapani,

On 15/01/2021 12:35, Tapani Tarvainen wrote:
> Dear all,
>
> The version of sslh in IPFire now, 1.7a, is very old, some 10 years,
> and its parameters are hardcoded in /etc/init.d/sslh for one specific
> use case (IPFire admin access).
>
> I have a different use case for it: sharing port 443 with OpenVPN and
> a web server in Orange. That would be easy with a more recent version
> of sslh (OpenVPn first appeared in 1.8 in July 2011).
>
> So I'd like to update the sslh AddOn with
>
> (1) A more recent version of sslh. Latest upstream version is 1.21,
> released on 11 July 2020, and I see no obvious reason not to use it,
> although for the present purpose some older version might do as well.
>
> Are there some specific procedures for updating AddOn binaries?
It is not a binary in the sense I would understand. The source file has c code in it that the required binaries are created from using the Makefile with autotools. Are you meaning something different from your comment?
> (2) Parameters in a configuration file. I'd be happy to edit it by
> hand, writing a GUI for it would probably not be worth the trouble.
>
> Is there some convention or guidelines where in IPFire such
> configuration files should be put? Debian uses /etc/defaults/sslh,
> sslh changelog presently suggests /etc/sslh.cfg.
The addons generally have any config files either directly under /etc or in a directory under /etc named after the addon program.
> Should a default configuration file be packaged as a separate
> file, or should the init script create one if it's missing
> or should it just use the hardcoded defaults in that case?

I would say that is up to the person updating the addon. sslh has its own addon page in the wiki but it isn't listed in the main addons page that lists all addons. You can only find it with the search bar in the wiki or if you know the url. https://wiki.ipfire.org/addons/sslh

My feeling would be not to have a specific use case hard coded in the init script but rather have a default config file. The source file includes a basic.cfg which could be used to fill that role. Then the addon page could be extended to mention about the cfg file and the need to review it before starting sslh.

> Are there guidelines or instructions for doing or proposing such
> changes to AddOns?
The wiki page on building addons can also be applied to updating or upgrading them. It helped me when I was first starting with updating the bacula addon. https://wiki.ipfire.org/devel/ipfire-2-x/addon-howto
> I can't even find a category for them in the Bugzilla. Is there one?
>
> My apologies if I'm missing something obvious, pointers to
> documentation would be welcome.
>
Hope the above inputs help.

Regards,

Adolf.


  reply	other threads:[~2021-01-15 12:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 11:35 Tapani Tarvainen
2021-01-15 12:43 ` Adolf Belka [this message]
2021-01-15 13:22   ` sslh Tapani Tarvainen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01c25fd8-7fd8-9d2e-c445-92fcc89bafe0@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox