Bug 147921 - net-proxy/sshproxy-0.5.0 version bump
|
Bug#:
147921
|
Product: Gentoo Linux
|
Version: 2006.0
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: net-proxy@gentoo.org
|
Reported By: david+gentoo@guerizec.net
|
|
Component: Ebuilds
|
|
|
URL:
http://penguin.fr/sshproxy/
|
|
Summary: net-proxy/sshproxy-0.5.0 version bump
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-09-17 05:54 0000
|
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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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...
