Re: sshd didn't run after upgrade to FreeBSD 8.4
On Thu, Jun 20, 2013 at 4:28 AM, Lee Dilkie wrote:
>
> On 6/19/2013 8:24 PM, Kimmo Paasiala wrote:
>> Ok, this is crazy. If you put one space after the VersionAddendum
>> keyword you get exactly what you want, an empty VersionAddendum
>> string. If there's no space but a newline right after the
>> VersionAddendum keyword, sshd(8) complains about the line and refuses
>> to start. So this is ok (without the single quotes, they are just to
>> show the endings of the lines):
>>
>> 'VersionAddendum '
>>
>> But this is not:
>>
>> 'VersionAddendum'
>>
>> What are the OpenSSH devs thinking?
>>
>> -Kimmo
>
> I'd call it a bug.
>
crypto/openssh/servconf.c
1553 case sVersionAddendum:
1554 if (cp == NULL)
1555 fatal("%.200s line %d: Missing
argument.", filename,
1556 linenum);
1557 len = strspn(cp, WHITESPACE);
1558 if (*activep && options->version_addendum == NULL) {
1559 if (strcasecmp(cp + len, "none") == 0)
1560 options->version_addendum = xstrdup("");
1561 else if (strchr(cp + len, '\r') != NULL)
1562 fatal("%.200s line %d: Invalid argument",
1563 filename, linenum);
1564 else
1565 options->version_addendum =
xstrdup(cp + len);
1566 }
1567 return 0;
Looks like if you specify:
VersionAddendum none
it won't display the additional info.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/21/13 16:04, Miroslav Lachman wrote: > 1) Is there some way to create relative symlinks with OpenSSH 6.1? No. It seems like a regression and can not be worked around. I do have a patch (attached; against crypto/openssh/), and my test shows that it would fix the problem. > 2) Was OpenSSH 6.1 tested before importing in to the base of > FreeBSD 8.4 release? These two bugs seems serious to me. This code is not new: it was in OpenBSD 3 years ago, and in FreeBSD for more than 2 years (r221420 or 2011-05-04); OpenSSH 6.1 was imported last September. This issue you have just raised have been there since FreeBSD 9.0-RELEASE. So to me it seems like that the two issues are either rarely hit by the general public (counting myself in: I have never used sftp to create symbolic link remotely and have thus learned something new today), or those who hit this have choose to keep silent about it. Fortunately we have you noticed and reported the problem. As a community effort, we really *need* people to grab in-development snapshots and provide us the feedback. > 3) Is there any chance to fix these bugs in FreeBSD repository, or > do we need to be "bug to bug" compatible with other systems using > OpenSSH 6.x? I can not make a promise as I am not the maintainer. However, I have already reported this issue to upstream OpenBSD developers, so if this was accepted by the upstream, we will commit the change locally to fix the issue. Unfortunately, it is too late to fix this for 8.4-RELEASE, and unless we see widespread complain, I don't think the problem would affect a significant amount of users to warrant a "errata" for supported release (8.4-RELEASE, 9.1-RELEASE), however, if it would be fixed, the fix would be merged to 8-STABLE and 9-STABLE and will be shipped with future releases, if the fix enters the development branch before them. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRxPXUAAoJEG80Jeu8UPuzzRAH/AnNKnmsb6vX9LCNRsLtb2SG bk2J4lx5XLK3sCYEeSL/npBtpwShGLMRnfTeb7oAPBU0skzpppHDpvwp8aIZUAGB uMwMrln2YPKYfUJvtkPdUC+5Jm8OHnxwoYepOXkZSQy8R3ii1Q2Kpk9uGbez1i2i iFaP+bQoCJxX8NdTRE/WrPjpfgq8KvUOowBn21dGLZ+MGUL5RlffvrOgth8Py4rp ByekHuvwNz0i5wxILmriPKg04MhI8Ljy6Y8KxjZhn6v3fjEO7D5FvVlJP8us9iu0 AsFbnkBOvaYxJFDCmlh7u4fumCcsvtwmsmNbiqFRdQVbDuyMdvf880kNrmgCb5k= =vS/U -END PGP SIGNATURE- Index: usr.bin/ssh/sftp.c === RCS file: /home/openbsd/src/usr.bin/ssh/sftp.c,v retrieving revision 1.143 diff -u -p -u -r1.143 sftp.c --- usr.bin/ssh/sftp.c 18 Apr 2013 02:16:07 - 1.143 +++ usr.bin/ssh/sftp.c 22 Jun 2013 00:26:00 - @@ -1313,7 +1313,6 @@ parse_dispatch_command(struct sftp_conn case I_SYMLINK: sflag = 1; case I_LINK: - path1 = make_absolute(path1, *pwd); path2 = make_absolute(path2, *pwd); err = (sflag ? do_symlink : do_hardlink)(conn, path1, path2); break; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issue with svn updates both source and ports.
On Fri, Jun 21, 2013 at 5:51 PM, David Wolfskill wrote: > On Fri, Jun 21, 2013 at 05:45:42PM -0500, Edwin L. Culp W. wrote: > > I've been using svn updates for some time with no problems rebuilding > > daily. > > > > Version of my last successful update. > > # uname -a > > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 > #503 > > r252026: Thu Jun 20 06:41:28 CDT 2013 > > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > > amd64 > > > > # cd /usr/src && svn up /usr/src > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: The working copy at '/usr/src' > > is too old (format 29) to work with client version '1.8.0 (r1490375)' > > (expects format 31). You need to upgrade the working copy first. > > You need to do as the above message suggests: "svn upgrade /usr/src". > (Note that "svn up" is short for "svn update", which is different from > "svn upgrade".) > David, thanks, you are a life saver. I had missed the above completely. > > This is a result of the svn client (now) being 1.8.x, vs. the last > successful "svn up", when it was 1.7.x. > > > # cd /usr/ports && /usr/local/bin/svn up /usr/ports > > Updating '.': > > svn: E17: Unrecognized URL scheme for ' > > https://svn0.us-west.freebsd.org/ports/head' > > This is likely an issue of the new 1.8.x svn client not being built with > SERF support. Please see ports/UPDATING, entry 20130619. > > Now using 1.8 and making world. I seem to be coming out of this problem, thanks to you. In the morning I will see the final results and let you and the list know. Maybe someone else will miss understand these changes. Have a great weekend. ed > > ... > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Bienes Raíces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/102249989850215?sk=photos_albums ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)
Beside my previous complaint about sshd not starting after upgrade from FreeBSD 8.3 to 8.4 due to incompatible change in parsing sshd_config with empty VersionAddendum [1], there is another more serious bug in newly imported SSH in base (OpenSSH_6.1p1) which I am not able to fix / workaround. In short: OpenSSH 6.1 is creating broken symlinks with sftp command on OpenSSH 5.4 server with chrooted account. It will always creates symlinks with pseudo absolute path instead of relative. SSH server (OpenSSH 5.4 on FreeBSD 8.3) is configured with the following settings for chrooting: Match User devel ChrootDirectory /usr/home ForceCommand internal-sftp And again, it was working fine with older version of FreeBSD / OpenSSH 5.4 client (sftp command). It is working with WinSCP too. The sftp command used for creating the symlink is: symlink temp temp_symlink Expected result shown by ls -l /usr/home/devel on server side is: temp_symlink -> temp Broken links by OpenSSH 6.1 client: temp_symlink -> /devel/temp So the symlink is not working outside of the sftp chrooted session (for example, Apache cannot read files from symlinked directory because only user "devel" is chrooted) I tried to enable DEBUG logging in sshd_config on the server side with following results: Expected behavior with OpenSSH 5.4 as sftp client subsystem request for sftp session opened for local user devel from [y.y.y.y] received client version 3 realpath "." symlink old "temp" new "/usr/home/devel/temp_symlink" sent status Success session closed for local user devel from [y.y.y.y] Broken behavior with OpenSSH 6.1 as sftp client subsystem request for sftp session opened for local user devel from [x.x.x.x] received client version 3 realpath "." opendir "/usr/home/devel" sent status End of file closedir "/usr/home/devel" sent status Success symlink old "/usr/home/devel/temp" new "/usr/home/devel/temp_symlink" sent status Success In both cases the sftp command is executed from simplified shellscript simulating much larger script for our application deployment: echo "symlink temp temp_symlink quit " | sftp devel@x.x.x.x The above debug output is the same with sftp-server and internal-sftp (in sshd_config). It does not matter if user account is chrooted or not - sftp command always creates symlink with an absolute path (with OpenSSH 6.1). With OpenSSH 5.4 client, it will create relative path symlinks as expected. So my questions are: 1) Is there some way to create relative symlinks with OpenSSH 6.1? 2) Was OpenSSH 6.1 tested before importing in to the base of FreeBSD 8.4 release? These two bugs seems serious to me. 3) Is there any chance to fix these bugs in FreeBSD repository, or do we need to be "bug to bug" compatible with other systems using OpenSSH 6.x? Miroslav Lachman [1] sshd didn't run after upgrade to FreeBSD 8.4 http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073898.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issue with svn updates both source and ports.
On Fri, Jun 21, 2013 at 05:45:42PM -0500, Edwin L. Culp W. wrote: > I've been using svn updates for some time with no problems rebuilding > daily. > > Version of my last successful update. > # uname -a > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #503 > r252026: Thu Jun 20 06:41:28 CDT 2013 > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > amd64 > > # cd /usr/src && svn up /usr/src > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/usr/src' > is too old (format 29) to work with client version '1.8.0 (r1490375)' > (expects format 31). You need to upgrade the working copy first. You need to do as the above message suggests: "svn upgrade /usr/src". (Note that "svn up" is short for "svn update", which is different from "svn upgrade".) This is a result of the svn client (now) being 1.8.x, vs. the last successful "svn up", when it was 1.7.x. > # cd /usr/ports && /usr/local/bin/svn up /usr/ports > Updating '.': > svn: E17: Unrecognized URL scheme for ' > https://svn0.us-west.freebsd.org/ports/head' This is likely an issue of the new 1.8.x svn client not being built with SERF support. Please see ports/UPDATING, entry 20130619. > ... Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp1cIxvcXU0d.pgp Description: PGP signature
Issue with svn updates both source and ports.
I've been using svn updates for some time with no problems rebuilding daily. Version of my last successful update. # uname -a FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #503 r252026: Thu Jun 20 06:41:28 CDT 2013 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 # cd /usr/src && svn up /usr/src svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/usr/src' is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first. # cd /usr/ports && /usr/local/bin/svn up /usr/ports Updating '.': svn: E17: Unrecognized URL scheme for ' https://svn0.us-west.freebsd.org/ports/head' Today was the first day that I have seen this. The error message leads me to believe that I am out of date but have tried to find a way to upgrade and haven't been successful. The ports versions have not changed for svn didn't update them today. Maybe I should update differently? Thanks, ed - -- Bienes Raíces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/102249989850215?sk=photos_albums ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Thu, 20 Jun 2013 14:19:21 -0700, Adrian Chadd wrote: > Hi, > > FreeBSD-9 works fine on this Lenovo T400 - except that suspending with > no USB devices plugged in result in no ports working after resume. > > If I have a device plugged in during suspend - on any port - then all > the ports work fine after resume. > > I've attached usbconfig and acpidump output. No acpidump output on -stable or -acpi anyway .. likely best as an URL, if it comes down to ACPI. So the fingerprint reader, camera and bluetooth shown in your usbconfig don't serve as 'USB devices plugged in' in this regard? Do they work ok after resume, or not? > here's what is logged in the kernel buffer during suspend and resume: > > > Her'es the suspend: With all but the USB-related stuff dropped, I assume? > Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34 > Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.2: at usbus1 > (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.3: at usbus1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: ugen3.2: at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2 > (disconnected) > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0 > outstanding, 1 refs > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry > Jun 20 14:03:47 lucy kernel: ugen3.3: > at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect The last message is news to me. > Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1 > (disconnected) > > ..and resume: I wonder what these devices are? > > Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power > state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER No, the above are still on the suspend path, but logged on resume. I don't know what CDBS or EXP0,1,3,4 are. You've left out something like 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right? On 9(.1-R so far) I always get the same sort of messages for the cardbus slots on my T23, eg pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER, also for CBS1. I've supposed it meant there was no D2 setting for these and they seem to resume alright, later on: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 (& CBS1) I suppose you'd have lines setting state back to D0 on these, later on? > Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button > status > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect > Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06) I hope 'slept' message is still in 10, I've seen a few listed without, and they're very handy if there's any resume delay, as I had up to 8.2 (plus exactly 60 seconds) unless I unloaded (in particular) UHCI and reloaded it on resume, needing a kernel w/out uhci, ohci and ehci, loading on boot and unload/reload in rc.suspend/resume. This however was fixed by 9.1 for me, the first release where suspend/resume works flawlessly on the T23. I haven't tried a recent 9-STABLE though. > Jun 20 14:03:47 lucy kernel: [100067] uhub0: class 9/0, rev 2.00/1.00, addr 1> on usbus7 > Jun 20 14:03:47 lucy kernel: [100046] uhub1: class 9/0, rev 2.00/1.00, addr 1> on usbus3 > Jun 20 14:03:47 lucy kernel: [100031] uhub2: class 9/0, rev 1.00/1.00, addr 1> on usbus0 > Jun 20 14:03:47 lucy kernel: [100036] uhub3: class 9/0, rev 1.00/1.00, addr 1> on usbus1 > Jun 20 14:03:47 lucy kernel: [100057] uhub4: class 9/0, rev 1.00/1.00, addr 1> on usbus5 > Jun 20 14:03:47 lucy kernel: [100052] uhub5: class 9/0, rev 1.00/1.00, addr 1> on usbus4 > Jun 20 14:03:47 lucy kernel: [100062] uhub6: class 9/0, rev 1.00/1.00
Продвижение предложений
Доброe время суток! Меня зовут Константин. Наша фирма занимается продвижением любых товаров и услуг в сети. Есть к Вам предложение: Ваш товар или услугу можно написать в предложении и распространить его по email адресам. Стоимость услуги - совсем невысокая. В случае заинтересованности - я соберу для Вас базу по необходимым критериям. Было бы интересно Вам попробовать предлагаемый метод поиска клиентов? Заранее благодарен за ответ Константин. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
