similar to: [Bug 310] New: sshd reporting ai_socktype errors when using ssh -X to server

Anyone from the Tru64 camp have any comments? Ken, can you log this into http://bugzilla.mindrot.org/ to ensure we don't lose the bug report? Thanks. - Ben ---------- Forwarded message ---------- Date: Thu, 27 Jun 2002 11:25:02 -0400 (EDT) From: Ken Kleiner <ken at cs.uml.edu> To: secureshell at securityfocus.com Cc: Ken Kleiner <ken at saturn.cs.uml.edu> Subject: sshd and

http://bugzilla.mindrot.org/show_bug.cgi?id=551 Summary: ssh install fails on Tru64 V5.0A Product: Portable OpenSSH Version: -current Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

I've just compiled 2.5.6 release on Tru64 V5.0A (configure detects alphaev67-dec-osf5.0, gcc release is a 3.1.1). rsync fails using rsync://<hostname>/ syntax. > lct@goliath(32) [rsync-2.5.6]$ ./rsync rsync://stitch/ > rsync: getaddrinfo: stitch 873: servname not supported for ai_socktype > rsync error: error in socket IO (code 10) at clientserver.c(83) Is there anyone else

http://bugzilla.mindrot.org/show_bug.cgi?id=310 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary| sshd reporting ai_socktype |sshd reporting ai_socktype |errors when using ssh -X to |errors when using ssh -X to |server

On 12/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for > ai_socktype [...] > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what > could have changed. How do I attempt to further debug/fix this? getaddrinfo(3) is a libc function - is it possible that libc was updated as well? I am

Charles, All, I just updated the kernel on my Arch box (the one we have been working on nut with on this list). Now upsd fails to start. (upsdrvctl is fine). I've posted working then -- Reboot -- the failing log information below. The 'Reboot' was for the kernel upgrade: Dec 14 14:02:00 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Dec 14

On Dec 16, 2013, at 10:11 PM, David C. Rankin wrote: > On 12/16/2013 08:01 PM, Charles Lepple wrote: >> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: >> >>>> Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >>>> ai_socktype >> [...] >>>> The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't

On 12/16/2013 08:01 PM, Charles Lepple wrote: > On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > >> > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >> > ai_socktype > [...] >> > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what >> > could have changed. How do I attempt to further

http://bugzilla.mindrot.org/show_bug.cgi?id=310 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-05-14 22:55

On 12/17/2013 10:43 AM, David C. Rankin wrote: > Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" > as "3493" (could have just used "nut" from /etc/services): Sheepishly looking for a place to hide.... Yes there was a ':' there all right. Seems I was hit by a vi error: [12:04 phoinix:/etc/ups] # grep 3493 *.conf

On Dec 17, 2013, at 1:08 PM, David C. Rankin wrote: > On 12/17/2013 10:43 AM, David C. Rankin wrote: >> Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" >> as "3493" (could have just used "nut" from /etc/services): > > Sheepishly looking for a place to hide.... > > Yes there was a ':' there all

Now hold on there... you said the problem started when you updated kernels - not when you changed the config file - did you change the config file or was it wrong before and the old kernel accepted it anyway? ted On 12/17/2013 10:08 AM, David C. Rankin wrote: > On 12/17/2013 10:43 AM, David C. Rankin wrote: >> Huh? Why the : in Servname? So I just hardwired it passing the port

I've documented a desire to do this for a while, time to actually follow through and support connecting as a client to a TCP server. Note that it is desirable to support the plugin connecting to an encrypted server over TCP, then exposing the raw data over a local Unix socket; that aspect requires yet more work, left for another day. But even allowing an old-style client to connect to an

On 12/16/2013 09:06 AM, Charles Lepple wrote: > If you want, we can take a look at the output of the aforementioned udevd > command from your system. Please compress the output, and if the list bounces > it, I'll extract the relevant portion from the bounce message. > > I have a funny feeling we might either have a Debian-specific dependency on > 91-permissions.rules, or

http://bugzilla.mindrot.org/show_bug.cgi?id=306 Summary: ssh on Tru64 returns " Name does not resolv to supplied parameters" Product: Portable OpenSSH Version: -current Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: ssh

Trying to build rsync 2.6.0 on Solaris 8 (gcc 3.3.2) has revealed that some of the EAI_ defines exist on Solaris, but not all of them. This causes lib/getaddrinfo.c to fail compilation as EAI_MAX (and some others) is undefined. The patch below fixes this issue, but I haven't tested the specific error conditions represented by the defines. Bryan --- lib/addrinfo.h.orig 2001-12-05

hi, virt guys, This is Hongqing from Fedroa QA team. I try to forward the guest installation logs to host with virtio. I have used virsh edit <guestName> to add a channel, it works fine. I think it would be better if I can initialize it when I create the guest using virt-install, and virt-install also offers the option, I have tried below, but it does not work. virt-install

Hi All, I'm trying to get rsync to proxy through an apache httpd server to an rsync server. On the proxy, which has a direct connection to the internet, I've stopped the firewall and unset HTTP_PROXY and RSYNC_PROXY. I've configured the httpd to allow proxy requests as follows: <IfModule mod_proxy.c># ProxyRequests On <Proxy *> Order deny,allow Deny from all

Samba 2.0.7 running on Compaq Tru64 UNIX V5.0A with latest tru64 patches. "mget *" works OK, "mput *" or something like "mput *.bat" fails with the error message "find: bad option -maxdepth". Several questions - Anyone else come across this one? Would dropping back to 2.0.6 fix the problem? Could it be an issue with 2.0.7 on Tru64 V5? Regards, Brian