similar to: tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure', so how to build?

Displaying 20 results from an estimated 700 matches similar to: "tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure', so how to build?"

2002 Sep 04
2
uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
What do we loose by not having post-auth privsep? What code is executed between authorization and actual setting of the effective uid? On Tue, 3 Sep 2002, Chris Adams wrote: > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > It appears that the integration of the sia session setup will either > > have to be rethought or abandoned
2002 Sep 11
1
tru64 sia: move call of session_setup_sia() to do_setusercontext(), letting grantpty() and friends handle pty perms
Hi- Under privsep, I experimented with moving the session_setup_sia() out of do_child() and into do_setusercontext(), which is where the uids/gids are set to the final execution user. The call is made with a NULL tty, and this is functional provided that any later pty allocation uses grantpty() to set the device permissions. Logging in with this method shows that a utmp entry does get made for
2002 Aug 28
1
interested tru64 unix person - privsep patch against 3.4p1 + howto /regress
Hi- Unfortunately, I just found out about the patch that was available for tru64 privsep. I was entirely unaware that there was a lack of support. Will the patch be considered for approval if it is applied to 3.4p1, or does it have to be done against -current? The reason I'm asking is that I have 3.4p1 working as is, so I know if I have a problem it is likely related to the patch and not
2002 Aug 28
0
patch almost works on 5.1A openssh 3.4p1 - get in, but get kicked out (fwd)
Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13
2002 Aug 28
5
Tru64 privsep patch testing
OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch to 3.4p1. Partial success, in that it now works for me for logins to "root". Logins to ordinary accounts fail after authentication, when trying to set tty characteristics. See the excerpt from the debug messages below. This is for Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
2002 Aug 30
1
no, I see now, tru64 pty ownership wrong on entry to setup_sia, may need /usr/lbin/chgpt (WAS Re: Tru64 privsep patch testing)
Hi Toni, I'm sorry, I haven't had much time to work on this today. When I run sshd (from the patched snapshot) in a debugger, with a breakpoint early in setup_sia(), this is what I find after connecting with a client: (1) There are two sshd processes. One is running as root, and the other as the user I logged with using the client. The root process is the one in the debugger,
2001 Nov 08
0
openssh-3.0p1 + Tru64 4.0G: sia_ses_authent() always returns 0 (failure)
Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init()
2011 Aug 27
1
Make a function work on an environemnt
In my R learning I've come across a situation in which a piece of code that works on the work space outside a function does not work inside the function. WARNING THIS EMAIL CONTAINES THE CODE:#rm(list=ls()) THIS WILL CLEAR ALL OBJECTS FROM YOUR WORKSPACE! When I use rm(list=ls()) and then ls() it shows character(0) So I tried to make a quick function to speed this up as follows:
2005 Jan 05
1
[PATCH] kinit/kinit.c
A patch for a few more hiccups and trivialities in kinit.c: * The check_path() calls check for "/root" and "/old_root" - I believe that should be "/root" and "/root/old_root". * chdir("/") is recommended after pivot_root() * init_argv[0] isn't set properly to the basename pointed to by char *s - this fix also eliminates six lines of
2005 Jan 05
1
[PATCH] kinit/nfsmount.c path from bootp
kinit/nfsmount.c:mount_nfs_root() should use the bootpath specified by bootp/dhcp. If the "nfsroot" option is specified then it overrides the boot server bootpath and a message indicating the override is printed. --- klibc-0.194/kinit/nfsroot.c.orig 2005-01-05 04:13:47.043897880 -0700 +++ klibc-0.194/kinit/nfsroot.c 2005-01-05 04:13:09.316633296 -0700 @@ -66,34 +66,21 @@ const int
2004 Oct 22
1
[PATCH] off-by-one in asprintf/vasprintf
Fix an off-by-one in asprintf and vasprintf. The return of vsnprintf is the number of bytes *not* including the terminating '\0'. The size argument to vsnprintf is the number of bytes *including* the terminating '\0'. diff -u klibc-0.188/klibc/asprintf.c udev/klibc-0.188/klibc/asprintf.c --- klibc-0.188/klibc/asprintf.c 2004-10-22 12:07:22.678906352 -0600 +++
2004 Oct 25
1
chicken/egg between pipefs and initramfs/hotplug
I have a hotplug setup in initramfs. Everytime that modprobe is called I get a kernel oops: NULL pointer dereference: Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel NULL pointer dereference at virtual address 00000014 printing eip: c015db49 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 3 EIP: 0060:[<c015db49>] Not tainted
2005 Jan 05
2
[PATCH] getopt
Patch to guarantee __optptr initialization and to correctly increment optind for missing arguments. --- klibc-0.194/klibc/getopt.c.orig 2005-01-04 23:18:50.229222640 -0700 +++ klibc-0.194/klibc/getopt.c 2005-01-04 23:17:05.236184008 -0700 @@ -11,7 +11,7 @@ char *optarg; int optind = 1; int opterr, optopt; -static const char *__optptr; +static const char *__optptr = NULL; int getopt(int
2005 Jan 05
1
Status/future for klibc/initramfs
I'm wondering where things are on the roadmap for klibc and initramfs/early userspace. When will everything be harmonized with the kernel and be the default? What is left to do? I'm in my own little world, but I have a pretty good klibc/hotplug/udev/kinit early userspace that just works (for me). It's taken me a bit to get things to work because I just couldn't find all the
2007 Sep 26
13
Nice chassis for ZFS server
Hi, I just came across this box [0] (McKay Creek). Seems to be exceptional building material for ZFS based NAS/iSCSI unit. I especially liked the two extra system disks hidden inside the box ! Any one have an experience with these ? [0] http://www.intel.com/design/servers/storage/ssr212mc2 -- Regards, Cyril
2006 Jun 01
4
VT-ready workstation for SuSE10.1/Xen and Windows
I''m wondering if the new Dell Precision 490 workstation is/looks to be VT-ready, planning it for SuSE10.1/Xen and unmodifies Windows guest? From the system specs: 1-2 Dual-Core Intel Xeon 5000 series 64-bit processors Intel 5000X chipset Windows XP/Vista or Redhat EWS4 Linux
2010 Jan 22
0
Meetme conferencing - large deployment SIP or ZAP?
I've been asked by my company to setup a conferencing system to support up to 400 people on a conference calls, where all users will be dialling in frpm the PSTN. I am exploring using Asterisk meetme to do this. I have two questions in relation to this:- For Meetme conferences is it better to have all participants to dial in via SIP provider terminating to Asterisk via SIP/IAX, or use
2006 Oct 06
2
2.6.18 Kernel
Are there any plans for Redhat/CentOS to implement the 2.6.18 Kernel which adds support for the Core 2 Duo chipsets, i.e. 965, 975, and 946? Thanks, -Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20061006/efe217f2/attachment-0002.html>
2004 Sep 16
3
[PATCH] gen_init_cpio uses external file list
(Apologies to klibc@zytor.com for the re-send) This patch makes gen_init_cpio generate the initramfs_data.cpio from a file which contains a list of entries: file, dir, nod. I swapped the order of filename/location for the file arguments so that it would be more uniform with the dir and nod tyes. [thayne@torch linux-2.6.8]$ usr/gen_init_cpio --help ERROR: unable to open '--help': No such
2005 Jan 05
0
[PATCH] kinit/do_mounts.c:name_to_dev_t()
kinit/do_mounts.c:name_to_dev_t() has an inverted logic problem and also doesn't return the correct value for "/dev/nfs". --- klibc-0.194/kinit/do_mounts.c.orig 2005-01-05 01:59:29.250868616 -0700 +++ klibc-0.194/kinit/do_mounts.c 2005-01-05 02:34:30.486432256 -0700 @@ -103,7 +103,7 @@ if ( name[0] == '/' && !stat(name, &st) && S_ISBLK(st.st_mode) )