Rename "default" image type

[sarumpaet]

Releasing Hedy-1.0.0 with changed semantics for "default" wasn't very good, and "default" is an awful name anyways.
We should get rid of that and use a name that suits the image type better. Since we have "backbone" without the wizard already, what about using image names "wizard-notunnel", "wizard-vpn03", "wizard-tunnelberlin", "backbone" or similar?
Also see https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037260.html

[niccokunzmann]

I would say "wizard-notunnel" could be "wizard-direct" or "wizard-lan" because this describes that there is not no internet but your own.
We can also remove the "wizard" word. Only a handful of geeks knows that a wizard is not always a magician.

I would suggest:

• "wan-access"
• "vpn03-tunnel"
• "berlin-tunnel"

[pmelange]

I like "no-tunnel", "tunnel-berlin", and "vpn03-deprecated" along side "backbone"

[SvenRoederer]

In der Mailinglisten-"Diskussion" (https://lists.berlin.freifunk.net/pipermail/berlin/2018-February/036982.html) waren jetzt keine Tendenzen für Pro oder Contra abzusehen und daher blieb es erstmal bei der bekannten Namenswahl.

Von den hier gemachten Vorschlägen wäre ich für

"wizard-notunnel", "wizard-vpn03", "wizard-tunnelberlin", "backbone"

[SvenRoederer]

Aber das "blocker" label find ich jetzt übertrieben ...

[ghost]

"wizard-notunnel", "wizard-vpn03", "wizard-tunnelberlin", "backbone"

+1

"*-deprecated"

For consistency, I'd put deprecation/experimental/beta/git/etc notes outside of the name.

[bobster-galore]

I think it's a nice idea to drop "default" since it doesn't mean anything.
We can have a long discussion what is more understandable to noobs either wizard or assistant but to me wizard sounds cute.

"wizard-notunnel", "wizard-vpn03", "wizard-tunnelberlin", "backbone"

I think wizard-* promises smthg while backbone sounds like u r left on ur own. Which is ok, I think.

Wizard is compatible with old and new (alternative) wizard.

By dropping default we support thinking about what to choose, which is nice as well.

[SvenRoederer]

ich würde jetzt innerhalb des Hedy-1.0.x zweiges aber nicht die Bedeutung ändern. Das sorgt für noch mehr Verwirrung.
Wir sollten das für's nächste release planen.

[bobster-galore]

If

"wizard-notunnel", "wizard-vpn03", "wizard-tunnelberlin", "backbone"

is the accepted wording we should go for it!
Can we close this?

[pmelange]

We can close this once the names have been changed in a commit and merged.

[pmelange]

I have created a new image type which, when the servers are ready, will allow tunneling through tunneldigger. There is still a lot of testing before it is ready. But since we are considering changing the names, I would like to get an important point accross....

I think the names should reflect the technology behind the uplink type. Not just which server group (which is also important), but also if openvpn or tunneldigger or potentially another technology is used.

On a development branch, I have renamed "tunnel-berlin" to "tunnel-berlin-openvpn" and added "tunnel-berlin-tunneldigger"

Aside from all of that, I'm still not sure if "wizard" is so necessary. Maybe "backbone" should be renamed to "backbone-experts-only" or "backbone-manual-config" and drop the "wizard" from the names.

[bobster-galore]

I'm easy with dropping "wizard" and using "(backbone-)manual-config".
I think it's nice to cut names short.

[SvenRoederer]

when introducing more uplinks, we should stop to create individual images for every uplink and remember that the plan was to find some generic way up select to uplink on runtime. Creating so many image-type is wasting ressources (storage-space and time on buildbots) and will confuse more. Having just a wizard-image and a backbone-image looks much more simple.

One option was to add all uplinks by default and then select the one to be used, the other option was to download the available uplink-packages and present the to the user for selection.

[sarumpaet]

I second what @SvenRoederer said.

With e08352d there's no real need to keep the tunnel.berlin and the VPN03 functionality separate anymore, and there's no good reason to keep the notunnel and the tunnel functionality in separate images: Users might want to switch quickly between both, and for maintainers it's a hassle to maintain both variants.

So I'd rather just close this ticket and try to unify down (again) to one end user image and one backbone/expert image.

[pmelange]

I would find it acceptable to have the wizard download and install the needed packages, configurations and keys (when necessary) for the different tunnel types.

Having everything pre-installed in am image is a total waste of space, especially for devices with limited flash. I don't mean only the 4mb devices. The 8mb devices also don't have much space left when openvpn is installed.

But since nobody has started coding a method to choose/switch between the different uplink types (vpn03-openvpn, tunnel-berlin-openvpn, tunnel-berlin-tunneldigger, ipredator-openvpn, and no-tunnel), then I think we should consider logical naming practices.

And most of all, I don't think a unified monolithic image should block new tunneling technologies like ipredator and tunneldigger.

[sarumpaet]

Download on demand seems fine to me (for numbers, it seems that the OpenVPN images are now at about 6MBytes; those without are at about 5.5MBytes).

Including other tunneling options via packages seems totally fine to me as well. 👍 But please don't introduce more prebuilt images.

[bobster-galore]

Would that mean we have "no-tunnel" and "manual-config" as images and while configuration u download if necessary ur favourite tunnel?
Sounds neat to me.

[bobster-galore]

Anyhow could it be nice to have an offline opportunity? U download the relevant packages and feed them offline to the router?

[pmelange]

Sure:

scp *ipk root@frei.funk:/tmp
ssh root@frei.funk
opkg install /tmp/*ipk

[bobster-galore]

I know, but if there are dependencies or are the packages all inclusive?

[pmelange]

No, the user would have to download all necessary ipk files. The download and install commands would probably go on a wiki page with copy and paste instructions.

Unfortunately it is currently not possible with openwrt's web interface to install packages or sets of packages offline.

[bobster-galore]

Can we build meta-packages for these? like luci-ssl?

[pmelange]

No. A meta-package is just a list of dependencies to download without adding any other "features" to the system.

[bobster-galore]

Do we skip offline possibility for now and give instructions on demand?
Do we agree on two images "no-tunnel" and "manual-config"?
Then we have to build a switch?

[SvenRoederer]

I'm ok with having an uplink -type "notunnel" in the firmware by default. When the user wants another uplink-type he has to download the current packagelist an select on of the uplinks defined there. Putting a list to pick from into the "Internet teilen" pages of the wizard should be avail when going to this concept.

When a user is looking for a predefined uplink for offline-install, he can always use the imagebuilder to inlcude it by default.

[sarumpaet]

It's not very intuitive to require users to download "notunnel" if they want to use a tunnel, isn't it?

I don't understand why "wizard" is bad. @pmelange Can you explain why you don't like "wizard"?
The main difference between the current "default" and "backbone" images is that the first one has the wizard, the latter doesn't, so why not just reflect that in the name?

[SvenRoederer]

@sarumpaet my reading of this issue is using following names finally:

• wizard
• manual-config

the wizard-flavor starts by default with the no-tunnel-configuration of the ffuplink and later can switch to a downloaded alternative type.
the manual-config is the current backbone

[pmelange]

@sarumpaet The reason why I stated that I didn't like wizard was because back when I made the comment was because there were going to be 4 wizard* images. What's the point in calling everything (expect one) a wizard. And what about people who aren't technologically inclined. I think the term wizard can lead to confusion.

If we do have an image which can handle many different uplink types, then I feel it needs to go into it's own Issue.

In the case where we do have just two images, then I think it would be better to have names which clearly state what the difference is between them. For example "auto-config" and "manual-config" would be very clear.

@sarumpaet, the difference between the out current "default" and "backbone" goes a lot deeper than just the wizard. The default image also uses the ffuplink style introduced in Hedy, freifunk-policy-routing, the luci-app-firewall package, and a well defined upgrade path (migration).

I'm disappointed that this issue is being referenced by #592 with the statement that "all agree". This issue is not closed yet. Ignoring the comments that are not to one's liking doesn't encourage people to participate.

I hope we can close this issue soon, create a ticket which states that we want to have an image which can install the desired uplink type on-demand with the ability to switch between uplink types, and that someone starts writing the code to implement this feature. Then we can eventually get it tested and added to a release.

[sarumpaet]

How about "wizard-config" and "manual-config"? :)
In any case, I wouldn't change image names now with the perspective of changing names again once that one wizard-handles-all-uplinks feature is there (hopefully soon).
I see that it's not great to reject the tunneldigger image by pointing to this issue. Perhaps we can get some work done on integrating tunneldigger (and possibly the other uplink types) into the wizard on the hackathon? I'd be happy to help with that.

[znrR]

can't be solved independently and relates to #601 - if theres a possibility to make similar choices as in #776 then we could do that. lets see how that progresses and then pick this topic up again. means: for now we stay with multiple releases per usecase: manual, no-tunnel, berlin-tunnel, tunnel-digger

[znrR]

closed by the group!