Re: Remote Debian installation assistance for newbies using WireGuard VPN
On Wed, 2018-04-25 at 18:17 +0200, Philip Hands wrote: > ST writes: > > > On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote: > >> ST writes: > >> > >> > Hello Debian Install System Team, > >> > > >> > there used to be Linux install parties - a very cool event in itself and > >> > a way to bring new users into community. However it is not so easy to > >> > organize and it is somewhat limiting in time and space. > >> > > >> > Several weeks ago I learned about the kernel-space VPN - WireGuard [1] > >> > and was so positively shocked by the ease of it's configuration/use [2] > >> > so that I don't stop to think how it can be effectively utilized. > >> > > >> > Today I was thinking whether it would be possible to use this technology > >> > to enable an experienced Linux user to help a fellow newbie to install > >> > Debian on his Windows box?... > >> > > >> > The idea is to add an "Remote assistance mode" into win32-loader. Once > >> > toggled - it will preseed and run Debian Installer (after reboot) > >> > without any interaction until it: > >> > 1. creates a WG interface, > >> > 2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3] > >> > (the assisting Linux profi also should be part of this VPN so he can SSH > >> > to the newbie through NAT). > >> > 3. runs SSH server listening on that IP. > >> > 4. generates a short random password for the root user and displays it > >> > together with its IP from step #2 on the monitor of the newbie. This > >> > information (IP and root's password) are communicated by newbie to his > >> > Linux profi friend by phone/sms/etc.. > >> > > >> >>From this point on the Linux profi can SSH to the box and continue the > >> > installation process in text mode. > >> > > >> > Is something like this possible? > >> > >> I've not yet used WireGuard, but from what I can see one needs a unique > >> key per client to be known to the server (perhaps there's a way of > >> telling it not to care). Also, the examples around the place also seem > >> to suggest that one needs a UDP port per connection. > >> > >> Also, the wireguard.com front page does currently say: > >> > >> WireGuard is not yet complete. _You should not rely on this code._ > >> > >> Anyway, I don't see that one actually needs WireGuard to implement it. > >> > >> A similar result could be achieved by configuring the new system to ssh > >> to a server somewhere, and either have that connection used for the > >> remote control, or have ssh also do port-forwarding back to the new > >> installation. > > > > Indeed?!... I'm positively shocked once again... Never knew it could be > > possible. Let's say we have a newbie (with a private IP - N which is > > behind NAT) and the same for a profie with IP P. And a publicly visible > > server with the IP S. Let's say both can SSH to S:22 and know each > > others' passwords/keys. > > > > Could you, please, describe in details how one can implement both > > approaches, namely: > > > > 1. "to ssh to a server somewhere, and either have that connection used", > > i.e. `ssh newbie@S:22`... so what now? How profi can get through to N? > > Many years ago I used to plumb things like this together with expect, > but there's bound to be a better way to do it these days -- tmate.io > (mentioned elsewhere in the thread) seems like it might be part of such > a solution. I doesn't trike me as the optimal approach though. > > > 2. "or have ssh also do port-forwarding back to the new installation" > > could you, please show the sequence of commands to achieve this? > > One would use something like this on the target system: > > ssh -R 0:localhost:22 newbie@S After several days of trials I came to following simple solution - there is no need for two accounts, just one, and it works like this: autossh -M 8000 -f -N -T -R 10023:localhost:22 -p 8482 pub...@debiantunneling.org - where 10023 is a random port chosen by Debian Installer together with a random root password to be communicated to the profi - 8482 is a custom SSH port - 8000/8001 is used by autossh to monitor the connection > which leaves you with the challenge of telling the "profi" the port > that's been allocated, which is probably scr
ITP: ecere -- The Ecere SDK is a cross-platform toolkit for building software applications. The SDK includes a compiler for the eC language, and its lightweight runtime environment includes a GUI tool
Package: wnpp Severity: wishlist Owner: Jerome St-Louis * Package name: ecere Version : 0.44.01 Upstream Author : Ecere Corporation & Contributors * URL : http://www.ecere.com/ * License : New BSD Programming Lang: eC Description : The Ecere SDK is a cross-platform toolkit for building software applications. The SDK includes a compiler for the eC language, and its lightweight runtime environment includes a GUI toolkit, a networking library and a basic 3D engine. Copyright (c) 1996-2012, Jerome Jacovella-St-Louis Copyright (c) 2005-2012, Ecere Corporation The Ecere SDK is a Software Development Kit including: * A set of compiling tools for the eC programming language ( http://www.ecere.com/technologies.html#eC ) * An Integrated Development Environment, with the usual features such as: - A source code editor with auto-completion, syntax highlighting - Management of application and library projects - A visual debugger - A Rapid Application Development form designer, based on properties & methods * A run time library, providing a uniform API across platforms, * featuring: - A GUI toolkit (with a vast collection of powerful controls: Buttons, Edit boxes, Drop/Combo boxes, Menus, Tabs, Tree views/Grids/List boxes, file dialogs, ...) - A 2D graphics API (bitmaps, fonts, international text, basic drawing) - A 3D graphics API, supporting both Direct3D and OpenGL (3DS file format support) - A networking API which provide Sockets as well as a distributed objects system for eC - System functionality such as file access, multi-threading & synchronization, handling date & time, etc. * Additional libraries and code for more features, such as: - The Ecere Data Access (EDA) layer, an abstract relational database API, providing an active record system for eC. Currently it has drivers for a minimal Ecere RDBMS and SQLite (as well as an encrypted version using SQLiteCipher), and recently a basic Oracle driver was introduced - An audio library (supporting DirectSound on Windows and ALSA on Linux) - WIA Scanning support on Windows - SSL Sockets suport through OpenSSL - A 2D tiled based game graphics engine (Tiled map, Sprites, A*) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAO19zatMsOY8=4mjisc_Oz48B68zEFfaEVv-Vjafkq0AuF=y...@mail.gmail.com
Re: Bug#781263: ITP: timgm6mb-soundfont -- TimGM6mb SoundFont from MuseScore 1.3
Fabian Greffrath writes: > The current name of the package is "musescore-soundfont-gm" and there > are two other soundfonts packaged in Debian in the "fluid-soundfont-gm" > and "fluid-soundfont-gs" packages. Maybe the name of the new package > should be chosen to be somewhat consistent with the existing packages. The Fluid soundfont is split into two parts: GM and GS. This does not apply for timgm6mb, so such naming doesn't make sense. Both names are descriptive, and are of the general schema name-soundfont[-specialisation]. Best, Toby -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oan9a7xq@tsmithe.net
Re: Bug#781263: ITP: timgm6mb-soundfont -- TimGM6mb SoundFont from MuseScore 1.3
Fabian Greffrath writes: > Am Dienstag, den 31.03.2015, 10:26 +0200 schrieb Toby St Clere Smithe: >> The Fluid soundfont is split into two parts: GM and GS. This does not >> apply for timgm6mb, so such naming doesn't make sense. Both names are >> descriptive, and are of the general schema >> name-soundfont[-specialisation]. > > I see. > > Have you considered a soundfont-name[-special] schema like the ones the > fonts-* or browser-plugins-* packages use? The fluid-soundfont-* > packages do not follow this schema (yet?), but others doing it wrong > should not keep oneself from starting to do it right, right? ;) Sure, indeed I have not. But I'm not sure right now it's worth the effort of migrating the names and dependencies. If we suddenly get a proliferation of soundfonts, then your suggestion is quite sensible. The proliferation is not happening soon: musescore-soundfont-gm is going away. I suppose another name could be tim-soundfont-gm, but that's not what people will search for (since here it's more widely known descriptively as TimGM6mb). Best, Toby -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv8l9za4@tsmithe.net
