similar to: [Bug 551] ssh install fails on Tru64 V5.0A

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

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=310 Summary: sshd reporting ai_socktype errors when using ssh -X to server Product: Portable OpenSSH Version: -current Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P3 Component: sshd AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=551 ------- Additional Comments From stock at stokkie.net 2004-03-17 06:21 ------- shouldn't this compiler warning be fixed first?? : cc: Warning: session.c, line 635: In this statement, the referenced type of the pointer value "&fromlen" is "unsigned long", which is not compatible with "int".

http://bugzilla.mindrot.org/show_bug.cgi?id=551 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 00:04 ------- Could you try adding a "#define BROKEN_GETADDRINFO 1" to config.h and then doing a "make clean ; make" (don't rerun configure after adding the #define) ------- You are receiving this mail because: ------- You are the assignee for the bug,

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

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

I cannot sem to find much info re installing Samba onto compaq's Alpha tru64 Unix v5.0a. can it be and if yes, why when I try to ru configure does it states it cannot execute? Thanks...Ian

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

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

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

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 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

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=306 ------- Additional Comments From cmadams at hiwaay.net 2002-06-28 00:31 ------- I'm not seeing this on Tru64 4.0G or 5.1A with OpenSSH 3.4p1. What does "rsh [server]" say? Are you using IPv6? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=533 Summary: sshd failure on Tru64 (OSF/1) 5.1a Product: Portable OpenSSH Version: 3.6p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: critical Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

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

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

I run Samba 2.2.2 on any of there vendors/osversions/filesystems: o Solaris 8 / ufs o Tru64 Unix V5.0A / advfs o RedHat 7.1 / Kernel 2.4.2 / ext2fs all these are capable of handling large files (files with a 64-bit-offset larger than 4GB). At configure time, samba selects the proper compile flags (-D_LARGEFILE_SOURCE, -D_FILE_OFFSET_BITS=64) for use with large files. The problem: When I