Hi

Freitag, 11. November 2011 you wrote:
> Hi,
>
> On 10/29/2011 10:34 PM, Markus Raab wrote:
> > Hello!
> >
> > Am Freitag, 28. Oktober 2011 schrieb Patrick Matthäi:
> >> Am 28.10.2011 12:17, schrieb Markus Raab:
> >>> Yes that step works perfectly, but the host would still be in
> >>> section "Unknown" if sudoers does not contain:
> >>> user  ALL=NOPASSWD:/usr/bin/aptitude update, /usr/bin/apt-get update
> >>>
> >>> Nevertheless manual verification what the problem is does not help
> >>> beginners which try apt-dater the first time - they are left without
> >>> any clue what was wrong or how it should be if it fails completely
> >>> silent.
>
> I absolutely agree that it should be some more verbose. There was a
> change off the output protocol of apt-dater-host which adds a diagnostic
> line (ADPERR) by apt-dater-host. Sadly, the CUI does not show up this
> line, yet.

If the connection fails completely (e.g. login with password) it also prints 
nothing.

> >>> best regards
> >>> Markus
> >>
> >> That is the reason why you should call after a sucessful connect
> >> "apt-dater-host status" :) Then you will see, if it works
> >
> > Thats not entirely true and that is exactly the problem ;)
> >
> > With the manual "apt-dater-host status" step you cannot see:
> > 1.) that ssh login with password is actually not supported in apt-dater
> > 2.) that the sudoers line given before is missing and the refresh will
> > actually fail
> >
> > To explain 2.) more detailled:
> > I have a host that does *not* contain the line
> > "user  ALL=NOPASSWD:/usr/bin/aptitude update, /usr/bin/apt-get update"
> > "apt-dater-host status" will output:
> > ADPROTO: 0.5
> > LSBREL: Debian|6.0.3|squeeze
> > pcilib: Cannot open /proc/bus/pci
> > lspci: Cannot find any working access method.
> > VIRT: Physical
> > UNAME: Linux|x86_64
> > FORBID: 0
> > ...
> > STATUS: cpio|2.11-4|i
> > KERNELINFO: 0 2.6.32-5-vserver-amd64
> >
> > How do I see with that information that updating the host will fail?
> > Even when I run "apt-dater-host refresh" it runs through without any
> > problems: ADPROTO: 0.5
> > Hit http://security.debian.org squeeze/updates Release.gpg
> > ...
> >
> > and then output as above.
> >
> > But when I press "g" in apt-dater the host will be moved to "Unknown".
> >
> > When I add
> > "user  ALL=NOPASSWD:/usr/bin/aptitude update, /usr/bin/apt-get update"
> > to sudoers, it will work as expected: The host is shows in "Up to date"
> > after I press g.
> >
> > Is this the behaviour as it should be?
>
> 'apt-dater-host refresh' has to update the package list which requires
> root privileges on apt-get hosts. The ADPERR line should give the
> correct error source (although it is not showed at the CUI, yet).

The output (without correct sudoers present) is:
---
ADPROTO: 0.5
sudo: no tty present and no askpass program specified

ADPERR: Failed to execute 'sudo aptitude update' (256).
---

Is this sudo line ok for that protocol?
To show the 'Failed to execute 'sudo aptitude update' (256).' in the CUI would 
help a lot I guess.

> > I additionally noticed now that "VIRT: Physical" is not correct, it seems
> > unable to detect vserver properly. Shall I open a bug report for that
> > too?
>
> Yes, please open a bug. It might be helpful if you supply the content of
> /proc/cpuinfo and the output of dmidecode along with the opening.

Ok, I found out that apt-dater-host uses imvirt internally which seems to have 
no support for vserver at all. 

cpuinfo gives no clue (it just says what it tells on the physical server too) 
and dmidecode just outputs:
# dmidecode 2.9
/dev/mem: No such file or directory

So I do not see an obvious way to support it. It would be just an low-priority 
feature request of an software which likely will be obsolete/removed next 
major debian release. So better get this apt-dater bug, which is much more 
annoying, fixed ;)

best regards
Markus



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to