New ebuilds for net-proxy/sshproxy-0.5.0_beta4 sshproxy can now be modular, so there are now 4 related ebuilds: sshproxy sshproxy-backend-mysql sshproxy-extra-plugins sshproxy-clients
Created attachment 97234 [details] net-proxy/sshproxy-0.5.0_beta4.ebuild This is the main ebuild
Created attachment 97235 [details] net-proxy/sshproxy/files/sshproxy.ini The default configuration file for sshproxy
Created attachment 97236 [details] net-proxy/sshproxy/files/sshproxyd.confd The conf.d configuration file for sshproxyd
Created attachment 97237 [details] net-proxy/sshproxy/files/sshproxyd.initd the init.d stratup script for sshproxyd
Created attachment 97238 [details] net-proxy/sshproxy-backend-mysql/sshproxy-backend-mysql-0.5.0_beta4.ebuild the optional mysql backend for sshproxy
Created attachment 97239 [details] net-proxy/sshproxy-extra-plugins/sshproxy-extra-plugins-0.5.0_beta4.ebuild A few optional plugins for sshproxy
Created attachment 97240 [details] net-proxy/sshproxy-clients/sshproxy-clients-0.5.0_beta4.ebuild The two client scripts pssh and pscp to connect to sshproxy
Created attachment 97242 [details] net-proxy/sshproxy/metadata.xml The metadata.xml file has not changed since version 0.4.x Question: do I have to make a different metadata.xml for each ebuild, or is it OK to copy this one in other sshproxy-* ebuilds ?
We don't need metadata.xml
I have the version 0.5.0-beta5 available, due to a minor security bug. Do I need to open a new ticket for that, or can I post here the new ebuilds ? They are not much different, only sshproxy-extra-plugins include a new plugin. Thanks.
Note: Please don't attach anything that hasn't changed. Sorry but I see no reason for breaking sshproxy into 2 ebuilds. The "extra-plugins" ebuild install just 2 small bash scripts! Please attach the diff of the new ebuild if that is the case. Other thing I want you to reconsider is dropping root privileges using setuid(). You really don't need to commute to root beside listen(). It would increase users security tremendously.
Ah, it isn't extra-plugins the one that install just 2 bash script... Anyway, please unify these 2 ebuilds and consider using USE flags (preferably the global ones) for enabling installation of the optional parts.
Created attachment 97474 [details] net-proxy/sshproxy/sshproxy-0.5.0_beta5.ebuild New unified ebuild for beta5 sshproxy-clients has its own package, because there is no relation (dependency) with the server package.
(In reply to comment #11) > Other thing I want you to reconsider is dropping root privileges using > setuid(). You really don't need to commute to root beside listen(). It would > increase users security tremendously. This has been done in the git tree, and will be available in the next release. Thanks for the advice.
(In reply to comment #13) > sshproxy-clients has its own package, because there is no relation (dependency) > with the server package. If you consider those 2 scripts as being part of another package, you should break the tarball in 2, the clients part having its own versioning scheme. But I really don't want to submit yet another a-couple-of-scripts package into the tree! Please make installation of the client scripts USE flag dependent. If you ask me, I would choose 2 local USE flag, one for client and the other for server. If neither is set, I would install both client & server.
(In reply to comment #15) > If you consider those 2 scripts as being part of another package, you should > break the tarball in 2, the clients part having its own versioning scheme. > But I really don't want to submit yet another a-couple-of-scripts package > into the tree! What is the reason to be reluctant ? > Please make installation of the client scripts USE flag dependent. If you ask > me, I would choose 2 local USE flag, one for client and the other for server. > If neither is set, I would install both client & server. Can you provide me with an example package that does this ? I'm sorry if I seem anal, but I don't see the point of having all in the same package, since there is clearly a server part, and a client one (which, I aggree, is only two shell wrappers around ssh for the moment). In a production environment, the clients don't need to be installed on the server, so I see two different packages. Please explain me your point. David
(In reply to comment #16) > What is the reason to be reluctant ? a) sshproxy-clients updates will be pointless. I think it is safe to say that those scripts will remain the same for all server versions. b) users don't really need these scripts to connect to a proxy since all they do is building a ssh command lines from environment variables that were set by the user anyway. c) the user must download the entire tarball just for installing 2 scripts which might fit very well in FILESDIR. > Can you provide me with an example package that does this ? Let me ask you another question. Can you give me an example of package foobar that have a corespondent foobar-clients ? Surely not packages like openssh or mysql, that's for sure. > I'm sorry if I seem anal, but I don't see the point of having all in the same > package, since there is clearly a server part, and a client one (which, I > aggree, is only two shell wrappers around ssh for the moment). > In a production environment, the clients don't need to be installed on the > server, so I see two different packages. Yes, those scripts aren't necessary on the server, but most server packages install client counterparts. Besides, what would be so wrong in installing them? Personally, I would use these flags: - clientscripts - Install client scripts only - mysql - obvious - minimal If you still insist in making 2 ebuilds, then I suggest to break the tarball in 2, representing packages with distinct versioning scheme.
Created attachment 98107 [details] net-proxy/sshproxy-0.5.0.ebuild This is the unified ebuild, as requested. Note that the version is now 0.5.0 Thanks
Created attachment 98179 [details] /sshproxy-0.5.0.ebuild Thank you for understanding! I've made a series of improvements: - replaced clientsonly with client-only - moved logs in /var/log/sshproxy - fix dependencies - quote variables that may contain spaces - parameterize mysql host and port - add "use mysq" in init script - set hostname in pkey_id - cosmetic code style changes I have a problem though, when I try to setup the proxy on a MySQL backend. The command "sshproxy-setup -c /etc/sshproxy -u sshproxy --add-admin mrness" don't have any effect on the MySQL database! Nothing appears in log files (beside loaded plugin lines, of course). Do you have any idea what could be the cause of this behaviour?
Created attachment 98180 [details] sshproxy.ini
Created attachment 98181 [details] sshproxyd.initd
Created attachment 98257 [details] sshproxy-0.5.0.ebuild There was a little bug in the ebuild. If mysql is used, we have to load the mysql_db plugin. I'll fix that in the code in the next release, but for now, it works with this ebuild. Thanks for your work!
fixed in cvs. good job! P.S. The secrets are now set to a hexadecimal number composed by 16 digits.
hmm, I just installed sshproxy-0.5.0 with USE="mysql". afterwards, I ran "emerge --config =net-proxy/sshproxy-0.5.0" just as the ebuild suggested. this appears: --8<-- Configuring pkg... Enter the MySQL host (default localhost): Enter the MySQL port (default 3306): * When prompted for a password, enter your MySQL root password * Enter password: --8<-- I entered the password and the setup script hangs. The MySQL database 'sshproxy' and the tables were successfully created though. An strace of the running process only shows this: --8<-- 12:47:17.527762 read(0, --8<-- The process in question is "/usr/bin/python /usr/bin/sshproxy-setup -u sshproxy -c /etc/sshproxy". Oh, I just pressed 'Enter' 8 times in a row and some menu appeared... but it is somewhat "broken". Running "/usr/bin/sshproxy-setup -u sshproxy -c /etc/sshproxy" manually works fine.
Also, sshproxy does not come with *any* manual pages or other documentation regarding /etc/sshproxy/sshproxy.ini :-((( This is *really* bad. Even http://penguin.fr/sshproxy/wiki/SshProxy/DocV0.5 does not explain pkey_id and auto_add_key (yes, that is an upstream problem, but as upstream is subscribed to this bug... ;)).
(In reply to comment #24) Strange, it worked for me just fine. I will have to re-test it.
Wolfram, I cannot reproduce it, even if I reinstall it like this: emerge -C sshproxy && rm -r /var/*/sshproxy /etc/sshproxy && emerge sshproxy && emerge --config sshproxy
I experience this on 2 different machines: Portage 2.1.1_pre4-r3 (default-linux/x86/2006.1/server, gcc-vanilla, glibc-2.3.6-r4, 2.6.16-gentoo-r8 i686) Portage 2.1.2_pre2-r9 (hardened/x86/2.6, gcc-3.3.6, glibc-2.3.5-r2, 2.6.14.7-grsec-2.1.8 i686)
(In reply to comment #25) > Also, sshproxy does not come with *any* manual pages or other documentation > regarding /etc/sshproxy/sshproxy.ini :-((( This is *really* bad. > Even http://penguin.fr/sshproxy/wiki/SshProxy/DocV0.5 does not > explain pkey_id and auto_add_key (yes, that is an upstream problem, but as > upstream is subscribed to this bug... ;)). I plaid guilty about the man pages, and I will add them in the next release. For explanations about pkey_id and auto_add_key, you have them in the menu of sshproxy-setup, when you select them in the interface: Public key id string ==================== Enter the public key id string used to identify the proxy public key that can be put in a remote .ssh/authorized_keys file. This is typically in the form of an email address. Public key id string [sshproxy@penguin.fr] Auto-add public key =================== If you want the auto-add-key feature, enter here the number of keys auto-added in the client keyring, or 'yes' for no limit. Saying 'no' disable this feature. Attention: this feature, if enabled, can be dangerous. Auto-add public key [no] But I should (will) probably add a paragraph in the documentation. Thanks for reporting. David
> Oh, I just pressed 'Enter' 8 times in a row and some menu appeared... but > it is somewhat "broken". > > Running "/usr/bin/sshproxy-setup -u sshproxy -c /etc/sshproxy" manually > works fine. What shell/term combination are you using ? Can you test and confirm (or infirm) that the bug occurs also with bash/konsole ?
(In reply to comment #29) > (In reply to comment #25) > > Also, sshproxy does not come with *any* manual pages or other documentation > > regarding /etc/sshproxy/sshproxy.ini :-((( This is *really* bad. > > Even http://penguin.fr/sshproxy/wiki/SshProxy/DocV0.5 does not > > explain pkey_id and auto_add_key (yes, that is an upstream problem, but as > > upstream is subscribed to this bug... ;)). > > I plaid guilty about the man pages, and I will add them in the next release. Great, thanks! > For explanations about pkey_id and auto_add_key, you have them in the menu of > sshproxy-setup, when you select them in the interface: Well, not the best place for documentation I believe ;) > Public key id string > ==================== > > Enter the public key id string used to identify the proxy public key that can > be put in a remote .ssh/authorized_keys file. This is typically in the form of > an email address. > > Public key id string [sshproxy@penguin.fr] That's unclear :( Where does the sshproxy daemon get the corresponding key from? From the homedir of the sshproxy daemon user? Where does it have to reside? Also, ssh public keys have just *comments*, mostly in the form of an e-mail address, but not necessarily. Next, such comments cannot be used to identify keys. Instead, fingerprints should be used. But anyway, I don't see why one should not instead specify a full path to the private key in the config. which looks like the best solution to me. > Auto-add public key > =================== > > If you want the auto-add-key feature, enter here the number of keys auto-added > in the client keyring, or 'yes' for no limit. Saying 'no' disable this feature. > Attention: this feature, if enabled, can be dangerous. > > Auto-add public key [no] What does this mean? It's unclear. Does it mean remote SSH host public keys, that are usually added to ~/.ssh/known_hosts? Please, improve the docs -- I am unable to use sshproxy right now because I don't understand how it works :( > Thanks for reporting. np :-)
(In reply to comment #31) > Please, improve the docs -- I am unable to use sshproxy right now > because I don't understand how it works :( May I ask you to ask your questions and continue this discution on the sshproxy@penguin.fr mailing list, so that all users can benefit the answers? I take your comments as a valuable contribution. Thank you.
(In reply to comment #30) > > Oh, I just pressed 'Enter' 8 times in a row and some menu appeared... but > > it is somewhat "broken". > > > > Running "/usr/bin/sshproxy-setup -u sshproxy -c /etc/sshproxy" manually > > works fine. > > What shell/term combination are you using ? > Can you test and confirm (or infirm) that the bug occurs also with bash/konsole > ? the client runs KDE and Konsole in a UTF-8 environment, logged in via SSH to the 2 mentioned machines (also UTF-8), "emerge --config sshproxy" running inside screen.
OK, I can reproduce it. I still don't know why, though...
David, any news? :)
