Bug 219143 – Why does avahi export an sftp service for all machines?

Bug 219143 - Why does avahi export an sftp service for all machines?

Summary:	Why does avahi export an sftp service for all machines?

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 5
Classification:	Red Hat
Component:	avahi (Show other bugs)
Sub Component:
Version:	5.0
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	beta
Target Release:	---
Assigned To:	Lennart Poettering
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:	Reopened

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2006-12-11 09:48 EST by Alexander Larsson
Modified:	2018-03-06 11:27 EST (History)
CC List:	7 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2010-01-13 07:24:41 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Alexander Larsson 2006-12-11 09:48:27 EST

Why does avahi (via /etc/avahi/services/sftp-ssh.service) export an sftp service
on *all* machines by default.

This means that browsing the network for shares in e.g. nautilus will display
all the machines on the local network. In almost all cases this is not what you
want.

Comment 1 Lennart Poettering 2007-06-25 18:52:04 EDT

Hmm, Why isn't this behaviour what you want? I think it makes a lot of sense to
be able to browse for all machines on the local LAN which you can access via sftp.

Comment 2 Alexander Larsson 2007-06-26 04:55:34 EDT

Say you have an office with 100 desktop machines, and a few servers, some that
have often uses sftp shares. Now, the desktop machines run sshd to allow remote
maintainance (if e.g. someone calls helpdesk). However, exporting all these as
sftp shares makes lan browsing for sftp shares practically useless. Its
impossible to find the important/interesting shares. 

I *specifically* asked the mDNS people for a separate _sftp type (in addition to
the _ssh one) in order to not run into situations like this. (And it was added.)

Comment 3 Lennart Poettering 2007-07-24 18:08:31 EDT

I guess you convinced me.

Any objections if I install ssh.sftp by default, then?

Comment 4 Lennart Poettering 2007-07-24 18:10:48 EDT

oops!

That should read: "Any objections if I install ssh.service" by default, then?"

I also forgot to mention that I am going to remove ssh-sftp.service from the
next package version.

Comment 5 Alexander Larsson 2007-07-26 05:25:48 EDT

ssh.service seems better suited for a default. Its not showing up much in
ordinary peoples UIs, and its mainly what ssh installs on desktops will be used for.

Comment 6 Lennart Poettering 2008-03-27 14:29:14 EDT

This has been fixed a while back now.

Comment 7 ritz 2009-01-31 05:46:22 EST

This bug was marked against RHEL5, and not fedora(rawhide) , and thus re-opening it.

-- ritz

Comment 13 Lennart Poettering 2009-11-13 21:09:58 EST

I'd like to commit a fix for this. But cannot, because of this:

*** Commit denied
*** Current RHEL-5 checkin policy requires:
    (rhel-5.5.0 == + or (rhel-5.5.0 == ? and pm_ack == +))

Not sure what's missing here...

Comment 17 errata-xmlrpc 2010-01-13 07:24:41 EST

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0034.html

Note You need to log in before you can comment on or make changes to this bug.