search

freifunk-gluon / gluon

a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes
https://gluon.readthedocs.io
Other
537 stars 325 forks source link

proposal: gluon-treatment #684

Closed viisauksena closed 8 years ago

viisauksena commented 8 years ago

some times special treatment of single nodes is handy or needed by comunitys ..

i build a package https://github.com/viisauksena/gluon-treatment - if we solve the problem of adding executable macs (like having a folder and copying it into) - this could be a standard repo. This would only be used to treat single nodes differently - by whatsoever reason.

but i also would agree if you think its "too" special - "too" whatever ..

neocturne commented 8 years ago

I think this is a very bad idea. We should try to build technologies that don't need special treatment for any reason, and certainly we should not build such special treatment into a firmware image.

If you need to do something special on a set of nodes you own, using SSH seems like the best choice.

viisauksena commented 8 years ago

background story

(we have some nodes which were installed like "fire and forget" .. and these are running and running, they are on difficult to reach locations, behind difficult to reach owners - which also wanted us to maintain the name and geo on the other hand

we also know some nodes, where adjustments has be done in config-mode , ignoring autoupdate procedures /compability )

i think the whole alias.json in meshviewer /ffmap-d3 follows the same idea, for me the more dirtier hack than this gluon-treatment, which correct things in the first place

special treatment while networks are fluid , they grow and change a lot - sometimes adjustments have to be done

i agree : you should not need this ! but if you need this : you will build something similar generic like this or a one-time-solution each time

neocturne commented 8 years ago

Does alias.json still exist? I thought it was removed some time ago... It was always only supposed to be used to add systems not running Gluon (i.e. gateways) to the map.

If you forgot to install your SSH key on nodes in hard-to-reach places, that is a problem, but I'd advise you not to burden the firmware with hacks to compensate for you negligence.

viisauksena commented 8 years ago

this is not we forgot something ... this is we designed to not have ssh by default

neocturne commented 8 years ago

I'm not talking about having SSH by default. I'm talking about having SSH on nodes you are supposed to control.

viisauksena commented 8 years ago

so in real life : 2 solutions are possible ...

  1. enable ssh on those nodes (i really know some location where you will not have this - "Parteibüro XY" for example)
  2. solve this as side-effect of a FW update (this proposal) its realy not missing something or bad design decissions .. its the question how comunity network maintainer solve issues in reality that come by - in one or another way,

(so many things people do : with more or less impact on your network : you can correct misleading geolocated nodes (northpole) , inapropiate nodenames (HeilHitler), alfred flooding (cat superfoo| alfred -s 158), convinient change deprecated branches (without extra branch FW) , remove unsecure ssh-keys )

so i see : you dont like the idea, its ok for me - that why this is a proposal to discuss (and not a merge request)

neocturne commented 8 years ago

The third option is to accept that you can't control a Freifunk network. Each node owner is responsible for his/her node, in my opinion you are absolutely not allowed to make such changes to a node without the explicit consent of the node's owner. The examples you gave are willful decisions of a node's owner, so changing them in updates won't be very productive anyways, as the owner can just revert the change.

There is a proverb which applies here: Don't try to find technical solutions for social problems. This applies to Freifunk even more, as Freifunk is a community project with a strong social component. Most issues of nodes are accidential misconfiguration and can be solved by talking to a node's owner. If the behaviour is actually malevolent, there isn't much you can do anyways...

neocturne commented 8 years ago

I agree though that it is important to discuss these issues here.

yayachiken commented 8 years ago

It is also possible to configure the web server which hosts the updates to deliver a custom manifest and image based on request IP address.

This is a bit of an hack, but has been tested doing "domain splits" in several Gluon communities already, and works pretty well.

viisauksena commented 8 years ago

i think we can close this here: conclusion is : this is nothing gluon will serve or maintain - because it is too much of a social problem solving. i agree with that. nevertheless, the package exists ... and if you dont want to kill a fastd key , and you dont want ssh in general, and you feel to have something corrected (which impacts on the map or network structure you maintain) - you can do so ... it's a hack, does not matter if its shipped via FW to all, or via special FW to single nodes. https://github.com/viisauksena/gluon-treatment