similar to: 6346201 patches 120900-02 and 120901-02 break patchadd

Author: comay Repository: /hg/zfs-crypto/gate Revision: f3f67f97f86c549d01e2d2ac2e266624d9ba3238 Log message: PSARC 2006/124 Configurable Privileges for Zones 4966416 RFE: zone privileges should be configurable 5008923 zoneadm halt message is a little illogical when run from the target zone 5049028 Makefiles that hacked around libpool errors now need cleanup 6345758 zonecfg rctl help

On Fri, Apr 24, 2015 at 08:32:45AM -0400, Scott Robbins wrote: > Wasn't Solaris, which for awhile at least, was probably the most popular > Unix, using ksh by default? Solaris /bin/sh was a real real dumb version of the bourne shell. Solaris included /bin/ksh as part of the core distribution (ksh88 was a part of the SVr4 specification) and so many scripts were written with #!/bin/ksh at

Hello, I just learned this morning about a new patch from Sun for Solaris 8 that adds /dev/random. The patch is based on the device in Solaris 9. I have not tried it yet, but I though some might be interested. The patch is: (this is available for free from sunsolve) Patch-ID# 112438-01 Keywords: secuity random number generator PRNG Synopsis: SunOS 5.8: /kernel/drv/random patch Date: Mar/28/2002

[Initial version of this message originally sent to zfs-interest by mistake. Sorry if this appears anywhere as a duplicate.] I was noodling around with creating a backup script for my home system, and I ran into a problem that I''m having a little trouble diagnosing. Has anyone seen anything like this or have any debug advice? I did a "zfs create -r" to set a snapshot on all

Author: jpk Repository: /hg/zfs-crypto/gate Revision: e7e07b2f4fcfbe725493f4074f9e9f0d8bfd8e1c Log message: PSARC/2002/762 Layered Trusted Solaris PSARC/2005/060 TSNET: Trusted Networking with Security Labels PSARC/2005/259 Layered Trusted Solaris Label Interfaces PSARC/2005/573 Solaris Trusted Extensions for Printing PSARC/2005/691 Trusted Extensions for Device Allocation PSARC/2005/723 Solaris

Has anyone gotten a transparent firewall working? I''m using snv_125 on an IBM x346 (snv_130 goes into endless boot loops on this hardware). I can create a working bridge with dladm, but can''t stop packets, even with "block in quick all". That stops packets on my management interface bge0, but not on the bridge. :( tim at ghost:~# ifconfig -a lo0:

I keep getting the following in the log files now that we've upgraded to the latest cvs 2.0 branch. Any ideas what we can do to fix this? Thanks! Bruce Mar 23 08:45:34 gate smbd[22692]: [1999/03/23 08:45:34, 0] smbd/oplock.c:oplock_break(773) Mar 23 08:45:34 gate smbd[22692]: oplock_break: end of file from client Mar 23 08:45:34 gate smbd[22692]: oplock_break failed for file COMM.INF

btenison@dibbs.net wrote: > > I keep getting the following in the log files now that we've upgraded to > the latest cvs 2.0 branch. Any ideas what we can do to fix this? > > Mar 23 08:45:34 gate smbd[22692]: [1999/03/23 08:45:34, 0] > smbd/oplock.c:oplock_break(773) > Mar 23 08:45:34 gate smbd[22692]: oplock_break: end of file from client > Mar 23 08:45:34 gate

Hi, in preparation to try zfs boot on sparc I installed all recent patches incl. feature patches comming from s10s_u3wos_10 and after reboot finally 137137-09 (still having everything on UFS). Now it doesn''t boot at anymore: ############################### Sun Fire V240, No Keyboard Copyright 2006 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.22.23, 2048 MB memory installed,

Hi I have been using dtrace script to monitor WiFi frames. For some reason, when I run the script I get the following error: dtrace: failed on compile script....line 56: operator -> can not be applied to a forward declaration: no struct ieee80211_frame definition is avaiable. And this is happening in all the scripts that use this structure. They were running fine previously. I had a few

Author: raf Repository: /hg/zfs-crypto/gate Revision: 594dc4b768c2510dd5d22f0a22b773dec0b3a19f Log message: 6359607 kstat perl module compiled with gcc breaks on x86 6359795 lpstat dumps core when compiled with gcc Files: update: usr/src/cmd/lp/Makefile.lp update: usr/src/cmd/lp/cmd/lpadmin/Makefile

Author: wyllys Repository: /hg/zfs-crypto/gate Revision: 1b97a96daa581c4f53b4fd8acceb76a27a9fe324 Log message: 6310540 6290437 causes gss_accept_sec_context not to output ret_flags whn no deleg cred; breaks ssh Files: update: usr/src/lib/libgss/g_accept_sec_context.c

Author: casper Repository: /hg/zfs-crypto/gate Revision: 24515d11f294677252853b5e1eb496c66b1e06e8 Log message: 6395215 UNIX03/UNIX98: *vsx* addition of mkstemps breaks namespace Files: update: usr/src/head/stdlib.h

Author: dchieu Repository: /hg/zfs-crypto/gate Revision: 6d3d0f5691e8f3cdbf8f1c0423cb60f6e14aa188 Log message: 6282991 snv_11 to snv_16 upgrade breaks touchpad mouse on acer aspire 1522WLMi Files: update: usr/src/uts/i86pc/io/acpica/acpi_enum.c

Author: jarrett Repository: /hg/zfs-crypto/gate Revision: a7ffb239fdca73019aac3eeb323ef82e106bf911 Log message: 6411400 Solaris trusted extensions putback breaks SC build Files: update: usr/src/uts/common/net/route.h

I am quite unfamiliar with DTrace (and even more with Solaris/Linux/other) kernel internals. I recently had to help look into an issue where an application apparently sent a UDP packet, but it did not appear on the wire, nor did snoop(1)ing the interface show it, so the assumption is that it was lost (or misdirected) somewhere in the IP stack. We did use Dtrace with syscall::sendto:entry/exit to

Author: Darren Moffat <darrenm at opensolaris.org> Repository: /hg/zfs-crypto/zfs-crypto-gate Latest revision: f2267f9eb807cc96d0d8ed72b186a4fae3490010 Total changesets: 1 Log message: merge with zfs-crypto-gate Files: delete: usr/src/lib/libcryptoutil/common/mechkeygen.c

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

First let me say I''m deeply sorry for the mail storm that seeding the new hg/zfs-crypto/gate repository caused. An explanation of what happened and why can be found on my blog: http://blogs.sun.com/darren/entry/sorry_mercurial_hg_push_oops There is also a discussion going on in the tools community on how to ensure this doesn''t happen again:

I plan to resync the zfs-crypto gate to onnv_73 to pickup some zfs core fixes and not get too far behind. I''m also planning for alpha release set of binaries by 1st November. I''ll send an update of what the alpha binaries will have working nearer the time. -- Darren J Moffat