Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Didier Carlier

On 04 Sep 2012, at 18:37, mag...@yonderway.com wrote:

 
 
 On Tue, 04 Sep 2012 17:06:06 +0100, James Relph ja...@themacplace.co.uk
 wrote:
 
 This to some extent goes back to something I've been talking about
 recently.  The current version of netatalk (v3) is actually excellent on
 OI.  NetAFP added cross-protocol file locking with the native CIFS client
 and netatalk will use ZFS xattrs to store Mac xattrs.The actual
 problem has turned out to be the Windows integration, because it's
 either:
 
 AD issues are going to require someone tenacious, motivated, and a bit
 masochistic as it's historically been a bit of a moving target.
 
 Low hanging fruit is to ignore the AD integration for now, make this a good
 NAS for home users without the AD integration issues resolved. Example of a
 common use case: iTunes media library. 2+ TB of music, movies, books,
 podcasts, etc. becomes more than a bit unwieldy to handle natively on a
 Mac, but Illumos is well suited to handle this workload. No AD integration
 is necessary for this use case. Local system auth is good enough.


The use case described is handled perfectly by OSX server ($15 these days...).
It might still be a good idea but don't believe that Mac users are waiting for 
such a NAS without any alternatives...


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] [discuss] SPARC and Illumos

2012-09-05 Thread Mark



One last thing: I bought a Dual 1.5GHz USIV Uniboard for V490 which is
located in Phoenix, but the seller strictly refuses to ship overseas.
Could smb. please help me and have it forwarded to Berlin?
This would be cool. But let's first get the DVD out.
I guess the seller can wait 2 more days. Later later  ...



I just bought a V890 for NZD 72.00 !! but that is for another task.
Glad I didn't have to ship it !!

But I do have a V440 waiting patiently for an OI install.
(4 x CPU, 8Gb mem 4 x 72Gb Hdd)

It can be made available for remote testing.

Mark.






tnx.
%martin

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] [discuss] SPARC and Illumos

2012-09-05 Thread Open Indiana
I disassembled my 2 V210 servers last year because I thought Sparc was
history. 
I only have 4 Ultrasparc IIIi  processors and memory that I saved from
disposal. 

To bad...

-Original Message-
From: Mark [mailto:mark0...@gmail.com] 
Sent: woensdag 5 september 2012 9:40
To: openindiana-discuss@openindiana.org
Subject: Re: [OpenIndiana-discuss] [discuss] SPARC and Illumos


 One last thing: I bought a Dual 1.5GHz USIV Uniboard for V490 which is 
 located in Phoenix, but the seller strictly refuses to ship overseas.
 Could smb. please help me and have it forwarded to Berlin?
 This would be cool. But let's first get the DVD out.
 I guess the seller can wait 2 more days. Later later  ...


I just bought a V890 for NZD 72.00 !! but that is for another task.
Glad I didn't have to ship it !!

But I do have a V440 waiting patiently for an OI install.
(4 x CPU, 8Gb mem 4 x 72Gb Hdd)

It can be made available for remote testing.

Mark.





 tnx.
 %martin

 ___
 OpenIndiana-discuss mailing list
 OpenIndiana-discuss@openindiana.org
 http://openindiana.org/mailman/listinfo/openindiana-discuss


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Frank Lahm
Hey James!

2012/9/4 James Relph ja...@themacplace.co.uk:

 AD issues are going to require someone tenacious, motivated, and a bit
 masochistic as it's historically been a bit of a moving target.

 AD seems reasonably stable these days, and in fact the current Illumos 
 strategy works 90% of the way, it's the idmap that actually breaks down 
 because of the approach taken with ephemeral UIDs.  It's the only system that 
 I've seen use that approach, and it just seems almost guaranteed to make it 
 difficult for apps that don't have the special hooks that the CIFS server 
 uses.  The opendirectoryd (Mac OS X) and winbind approaches seems much more 
 reliable - map a user to a generated UID which will be the same across the 
 domain.  Then apps don't need to worry about local or AD users, they just 
 work.

what about using winbind? Works with Netatalk and I guess it will also
work with Solaris CIFS.

We haven't been able to get supplementary groups working, but I'm
pretty sure that could be solved, possibly by installing an updated
winbind from sources.

-f

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] no permission to access oi_148 CIFS shares from Lion Finder

2012-09-05 Thread Martin Frost
Our users running Lion have a major access problem with CIFS shares
on an oi_148 machine.  The Finder is unable (or unwilling) to open
subdirectories of the share's top level.

The problem seems to be only in the Finder, since other programs
(e.g., Terminal or Pages) can navigate down through the CIFS tree.
For that matter, the Finder can access *files* in the top level, just
not subdirectories; for instance, QuickLook works on top-level files.

I don't know if this is really a Finder bug or a OI bug (or both), but
I've read that it was fixed in Nexenta before the end of November
2011.

Has this problem been fixed in OI?  Any chance for a fix in oi_148?

Thanks,
Martin

P.S. I just read of a strange temporary workaround, though I haven't had
a chance to test it.  It's in the post by notpeter on this page:

  https://discussions.apple.com/thread/3193468?start=30tstart=0

It'd be nice if our users didn't have to use that workaround to
access oi_148 files from the Finder in Lion.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread James Relph

 what about using winbind? Works with Netatalk and I guess it will also
 work with Solaris CIFS.
 
 We haven't been able to get supplementary groups working, but I'm
 pretty sure that could be solved, possibly by installing an updated
 winbind from sources.

Hi Frank,

Winbind worked straight away with netatalk, and was tons more 
reliable/configurable (you can just give it a UID range to use).  The problem 
was getting the Solaris CIFS server to work with it, which didn't seem to be 
possible.

James.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Frank Lahm
2012/9/5 James Relph ja...@themacplace.co.uk:

 what about using winbind? Works with Netatalk and I guess it will also
 work with Solaris CIFS.

 We haven't been able to get supplementary groups working, but I'm
 pretty sure that could be solved, possibly by installing an updated
 winbind from sources.

 Winbind worked straight away with netatalk, and was tons more 
 reliable/configurable (you can just give it a UID range to use).  The problem 
 was getting the Solaris CIFS server to work with it, which didn't seem to be 
 possible.

really? Can you elaborate? The thing is, I'm in the process of
compiling and updated winbind from latest Samba sources (and
documenting that process) in order to test with that if the problems
with supplementary groups go away and if it works with Solaris CIFS.

Thanks!
-f

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] no permission to access oi_148 CIFS shares from Lion Finder

2012-09-05 Thread Yuri Pankov

On Wed, 05 Sep 2012 03:37:16 -0700, Martin Frost wrote:

Our users running Lion have a major access problem with CIFS shares
on an oi_148 machine.  The Finder is unable (or unwilling) to open
subdirectories of the share's top level.

The problem seems to be only in the Finder, since other programs
(e.g., Terminal or Pages) can navigate down through the CIFS tree.
For that matter, the Finder can access *files* in the top level, just
not subdirectories; for instance, QuickLook works on top-level files.

I don't know if this is really a Finder bug or a OI bug (or both), but
I've read that it was fixed in Nexenta before the end of November
2011.

Has this problem been fixed in OI?  Any chance for a fix in oi_148?

Thanks,
Martin

P.S. I just read of a strange temporary workaround, though I haven't had
a chance to test it.  It's in the post by notpeter on this page:

   https://discussions.apple.com/thread/3193468?start=30tstart=0

It'd be nice if our users didn't have to use that workaround to
access oi_148 files from the Finder in Lion.


This should be fixed in illumos:

changeset:   13513:f84d4672fdbd
user:Gordon Ross g...@nexenta.com
date:Wed Nov 09 18:47:36 2011 -0500
description:
1718 MacOS X Lion (10.7) Finder access denied
Reviewed by: Dan McDonald dan...@nexenta.com
Reviewed by: Albert Lee tr...@nexenta.com
Reviewed by: Andrew Stormont andrew.storm...@nexenta.com
Reviewed by: Richard Lowe richl...@richlowe.net
Approved by: Eric Schrock eric.schr...@delphix.com

and should be available in the latest OI release (oi151a5, probably). 
The fix itself is pretty simple (attached).
changeset:   13513:f84d4672fdbd
user:Gordon Ross g...@nexenta.com
date:Wed Nov 09 18:47:36 2011 -0500
description:
1718 MacOS X Lion (10.7) Finder access denied
Reviewed by: Dan McDonald dan...@nexenta.com
Reviewed by: Albert Lee tr...@nexenta.com
Reviewed by: Andrew Stormont andrew.storm...@nexenta.com
Reviewed by: Richard Lowe richl...@richlowe.net
Approved by: Eric Schrock eric.schr...@delphix.com

diff -r 060607df0c9d -r f84d4672fdbd 
usr/src/uts/common/fs/smbsrv/smb_common_open.c
--- a/usr/src/uts/common/fs/smbsrv/smb_common_open.cTue Nov 08 17:01:06 
2011 -0500
+++ b/usr/src/uts/common/fs/smbsrv/smb_common_open.cWed Nov 09 18:47:36 
2011 -0500
@@ -20,6 +20,7 @@
  */
 
 /*
+ * Copyright 2011 Nexenta Systems, Inc.  All rights reserved.
  * Copyright (c) 2007, 2010, Oracle and/or its affiliates. All rights reserved.
  */
 
@@ -59,11 +60,15 @@
  *   FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, and FILE_APPEND_DATA
  *
  * GENERIC_EXECUTE STANDARD_RIGHTS_EXECUTE, SYNCHRONIZE, and FILE_EXECUTE.
+ *
+ * Careful, we have to emulate some Windows behavior here.
+ * When requested access == zero, you get READ_CONTROL.
+ * MacOS 10.7 depends on this.
  */
 uint32_t
 smb_access_generic_to_file(uint32_t desired_access)
 {
-   uint32_t access = 0;
+   uint32_t access = READ_CONTROL;
 
if (desired_access  GENERIC_ALL)
return (FILE_ALL_ACCESS  ~SYNCHRONIZE);

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] [discuss] SPARC and Illumos

2012-09-05 Thread Daniel Kjar
For all your hard work I can do that for you. I was thinking about how 
to buy you dinner



On 09/ 4/12 08:22 PM, Мартин Бохниг (Martin Bochnig) wrote:

Hi


ok, today I broke my rule and did login again.
Thanks for your encouraging pn's   :)



One update: After 8 years it was about time to get a new DVD burner,
these are unbelievably cheap now.
Connected to SB2k via off the shelf USB2 pci-controller with NEC chipset.

Now I can handle DVD-RAM media and finally use GROWISOFS(1m) for the first time.

This should speed up things a little bit, and be more efficient.

Ok, till later, when the LiveDVD is ready (this should definitely
happen during the next days).

One last thing: I bought a Dual 1.5GHz USIV Uniboard for V490 which is
located in Phoenix, but the seller strictly refuses to ship overseas.
Could smb. please help me and have it forwarded to Berlin?
This would be cool. But let's first get the DVD out.
I guess the seller can wait 2 more days. Later later  ...





tnx.
%martin

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


--
Dr. Daniel Kjar
Assistant Professor of Biology
Division of Mathematics and Natural Sciences
Elmira College
1 Park Place
Elmira, NY 14901
607-735-1826
http://faculty.elmira.edu/dkjar

...humans send their young men to war; ants send their old ladies
-E. O. Wilson



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Magnus

On Sep 5, 2012, at 2:59 AM, Didier Carlier wrote:
 
 The use case described is handled perfectly by OSX server ($15 these days...).
 It might still be a good idea but don't believe that Mac users are waiting 
 for such a NAS without any alternatives…

My iTunes library is pushing 2TB these days, and I'm not done backing up my 
large DVD collection yet. I've got a stack of external firewire drives attached 
to my Mac Mini that are slow (nature of Firewire) and suffer early thermal 
failure because these cases are designed more for looking slim and attractive 
on my desk than they are for actively cooling the disks within.  If I want to 
add new disks to expand my volume, I can't really do that; I have to make a 
full backup, destroy my original volume, and create a new volume with more 
disks in it.

I'm a beta tester for what was TensComplement so I have ZFS on there now, but I 
still have the limitations of firewire and the consumer level external disk 
thermal problems.

I very much have an interest in moving my precious media library to something 
more robust and performant. 

OS X Server doesn't fix any of that.

Meanwhile I've got a ~5 year old AMD machine that used to be a nice Linux 
desktop, now running Illumos (as of about 8 hours or so ago) and the long slow 
rsync from my Mac is still going. My disks will be actively cooled by a case 
with adequate fans. When my 2TB ZFS volume is a little closer to full, I can 
add another mirrored pair of 2TB disks to my pool in a matter of maybe half an 
hour tops (including time to physically install the disks). I've also got a 
pair of SSD's for slog and cache devices to put in there, once I source another 
SATA controller for the system. I can't do any of that with my Mac Mini.

I'm also looking at the *five disks* on my desk right now around my monitor, 
and smiling knowing that they are going away soon.

-M


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Didier Carlier

On 05 Sep 2012, at 14:21, Magnus mag...@yonderway.com wrote:

 
 On Sep 5, 2012, at 2:59 AM, Didier Carlier wrote:
 
 The use case described is handled perfectly by OSX server ($15 these 
 days...).
 It might still be a good idea but don't believe that Mac users are waiting 
 for such a NAS without any alternatives…
 
 My iTunes library is pushing 2TB these days, and I'm not done backing up my 
 large DVD collection yet. I've got a stack of external firewire drives 
 attached to my Mac Mini that are slow (nature of Firewire) and suffer early 
 thermal failure because these cases are designed more for looking slim and 
 attractive on my desk than they are for actively cooling the disks within.  
 If I want to add new disks to expand my volume, I can't really do that; I 
 have to make a full backup, destroy my original volume, and create a new 
 volume with more disks in it.
 
 I'm a beta tester for what was TensComplement so I have ZFS on there now, but 
 I still have the limitations of firewire and the consumer level external disk 
 thermal problems.
 
 I very much have an interest in moving my precious media library to something 
 more robust and performant. 
 
 OS X Server doesn't fix any of that.
 
 Meanwhile I've got a ~5 year old AMD machine that used to be a nice Linux 
 desktop, now running Illumos (as of about 8 hours or so ago) and the long 
 slow rsync from my Mac is still going. My disks will be actively cooled by a 
 case with adequate fans. When my 2TB ZFS volume is a little closer to full, I 
 can add another mirrored pair of 2TB disks to my pool in a matter of maybe 
 half an hour tops (including time to physically install the disks). I've also 
 got a pair of SSD's for slog and cache devices to put in there, once I source 
 another SATA controller for the system. I can't do any of that with my Mac 
 Mini.
 
 I'm also looking at the *five disks* on my desk right now around my monitor, 
 and smiling knowing that they are going away soon.
 
 -M


I wasn't talking specifically about firewire, a Thunderbolt disk array like the 
ones from Promise is much faster than firewire and support up to 12 TB.
That might be more expensive but functionally, a Mac mini plus this kind of 
storage handles your load without any problem.
Now obviously I agree that ZFS has its advantages, but OSX has some too, at 
least in a full Mac home or SME.





___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Illumos as a NAS

2012-09-05 Thread Magnus
I'd have to buy a new Mac to get Thunderbolt. It's a new feature that only the 
newest Macs have. Most Macs in the field now still don't have that option. Time 
will change that, of course. 

Sent from my iPhone

On Sep 5, 2012, at 8:58 AM, Didier Carlier did...@lafalise.org wrote:

 
 On 05 Sep 2012, at 14:21, Magnus mag...@yonderway.com wrote:
 
 
 On Sep 5, 2012, at 2:59 AM, Didier Carlier wrote:
 
 The use case described is handled perfectly by OSX server ($15 these 
 days...).
 It might still be a good idea but don't believe that Mac users are waiting 
 for such a NAS without any alternatives…
 
 My iTunes library is pushing 2TB these days, and I'm not done backing up my 
 large DVD collection yet. I've got a stack of external firewire drives 
 attached to my Mac Mini that are slow (nature of Firewire) and suffer early 
 thermal failure because these cases are designed more for looking slim and 
 attractive on my desk than they are for actively cooling the disks within.  
 If I want to add new disks to expand my volume, I can't really do that; I 
 have to make a full backup, destroy my original volume, and create a new 
 volume with more disks in it.
 
 I'm a beta tester for what was TensComplement so I have ZFS on there now, 
 but I still have the limitations of firewire and the consumer level external 
 disk thermal problems.
 
 I very much have an interest in moving my precious media library to 
 something more robust and performant. 
 
 OS X Server doesn't fix any of that.
 
 Meanwhile I've got a ~5 year old AMD machine that used to be a nice Linux 
 desktop, now running Illumos (as of about 8 hours or so ago) and the long 
 slow rsync from my Mac is still going. My disks will be actively cooled by a 
 case with adequate fans. When my 2TB ZFS volume is a little closer to full, 
 I can add another mirrored pair of 2TB disks to my pool in a matter of maybe 
 half an hour tops (including time to physically install the disks). I've 
 also got a pair of SSD's for slog and cache devices to put in there, once I 
 source another SATA controller for the system. I can't do any of that with 
 my Mac Mini.
 
 I'm also looking at the *five disks* on my desk right now around my monitor, 
 and smiling knowing that they are going away soon.
 
 -M
 
 
 I wasn't talking specifically about firewire, a Thunderbolt disk array like 
 the ones from Promise is much faster than firewire and support up to 12 TB.
 That might be more expensive but functionally, a Mac mini plus this kind of 
 storage handles your load without any problem.
 Now obviously I agree that ZFS has its advantages, but OSX has some too, at 
 least in a full Mac home or SME.
 
 
 
 
 
 ___
 OpenIndiana-discuss mailing list
 OpenIndiana-discuss@openindiana.org
 http://openindiana.org/mailman/listinfo/openindiana-discuss

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Reginald Beardsley
Thanks. 

--- On Wed, 9/5/12, Yuri Pankov yuri.pan...@gmail.com wrote:

 From: Yuri Pankov yuri.pan...@gmail.com
 Subject: Re: [OpenIndiana-discuss] stty source code
 To: openindiana-discuss openindiana-discuss@openindiana.org
 Date: Wednesday, September 5, 2012, 7:57 AM
 On Tue, 4 Sep 2012 14:40:29 -0700
 (PDT), Reginald Beardsley wrote:
  I've cloned the repository but find that the Makefile
 is expecting state to be set in the shell.  Where would
 I find details on what I need to have set to compile just
 the things in
 
  usr/src/cmd/ttymon
 
  Is that possible?  I'm really not eager to take on
 building everything as my OI box is a dual core Atom.
 
 http://wiki.illumos.org/display/illumos/How+To+Build+illumos
 
 ___
 OpenIndiana-discuss mailing list
 OpenIndiana-discuss@openindiana.org
 http://openindiana.org/mailman/listinfo/openindiana-discuss
 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] isc-dhcp client

2012-09-05 Thread Gary Gendel

Hi,

Anyone know if there is a fundamental reason why we can't wholesale 
replace the Sun/Oracle dhcp client with the ISC one?  If we don't get 
any updates downstream from Oracle we will never get features like ipv6 
prefix delegation.  This feature is becoming important as some big ISPs 
(i.e. Comcast) are using this to delegate IPV6 blocks to their 
business/personal customers.


If the answer is that I should be able to replace it, the next question 
is if anyone has done this before and how difficult this would be to do.


Gary


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Reginald Beardsley
I find that I am unable to convert a newline returned by a remote host to NL-CR 
for display in a terminal window. 

So instead of:

ok
ok
ok

I get:
 
ok
   ok
  ok

I thought I'd try to find out why.  I also found I can't actually set -onlcr 
w/ stty though I can toggle olcuc.  Some things in stty work and some don't.

I've actually modified the forth interpreter to send NL-CR and reassembled the 
code, so my original problem is solved.  But it bugs me that things don't seem 
to work properly.  While ttys are not used much now in the wider world, they 
are still heavily used as the interface to microcontrollers both for 
interaction and for loading new firmware.  

I'm *very* resistant to having to use Linux for this and simply won't use 
Windows which is the predominate environment for working w/ microcontrollers.  
Unfortunately there's a fair bit of open source stuff that doesn't like Solaris 
:-(  It was a good bit of work to get this far.

In view of the admin overhead, I'll probably defer working on ttymon  friends 
until I can setup a faster OI machine.  Working on OI wasn't actually in my 
plans at this time.

Thanks for the pointers.

Have Fun!
Reg

--- On Wed, 9/5/12, James Carlson carls...@workingcode.com wrote:

 From: James Carlson carls...@workingcode.com
 Subject: Re: [OpenIndiana-discuss] stty source code
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Wednesday, September 5, 2012, 7:52 AM
 Reginald Beardsley wrote:
  I've cloned the repository but find that the Makefile
 is expecting state to be set in the shell.  Where would
 I find details on what I need to have set to compile just
 the things in 
  
  usr/src/cmd/ttymon
  
  Is that possible?
 
 Look for the bldenv and ws scripts, part of the ON build
 tools in
 usr/src/tools.  A good starting point might be:
 
 http://hub.opensolaris.org/bin/view/Community+Group+on/devref_4
 
   I'm really not eager to take on building
 everything as my OI box is a
 dual core Atom.
 
 Building just a portion of the tree can be a little
 tricky.  In general,
 you have to do a make install in usr/src/head to make sure
 that you
 have a proto area with the right header files.  You
 might then be able
 to build in usr/src/cmd/ttymon, but it's very likely that
 you'll have to
 build some of the libraries on which it depends first.
 
 The ON build was never designed to allow builds of
 individual parts of
 the tree, except after building everything.
 
 An interesting (and possibly useful) project would be to
 break up the
 usr/src/cmd and usr/src/lib trees into separate projects, so
 that each
 can be built separately.  Doing so, though, likely
 requires a lot of
 careful planning so that flag-day changes are still
 reasonably doable.
 
 If you have a really slow target machine, it might be an
 interesting
 idea to work on a cross-compilation environment on a faster
 one.  I'm
 not sure, though, how hard that'd be.
 
 Why are you hacking at stty ... ?
 
 -- 
 James Carlson         42.703N
 71.076W         carls...@workingcode.com
 
 ___
 OpenIndiana-discuss mailing list
 OpenIndiana-discuss@openindiana.org
 http://openindiana.org/mailman/listinfo/openindiana-discuss
 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread James Carlson
Reginald Beardsley wrote:
 I find that I am unable to convert a newline returned by a remote host to 
 NL-CR for display in a terminal window. 
 
 So instead of:
 
 ok
 ok
 ok
 
 I get:
  
 ok
ok
   ok

It's unclear to me what problem you're trying to solve.  A terminal
window contains a terminal emulator that's displaying data from a
remote system.  The remote system decides what it will send, and that's
what stty affects.  Stty doesn't (normally, at least) affect what the
terminal window itself does with the data it sees.

The reason I say that is that the ok prompt you're showing looks like
it comes from a SPARC OBP prompt.  If it does, then what I think you'd
need is either an OBP command to change the CF/LF behavior or a
different terminal emulator or configuration.  OBP isn't UNIX and
doesn't have stty.

 I thought I'd try to find out why.  I also found I can't actually set 
 -onlcr w/ stty though I can toggle olcuc.  Some things in stty work and 
 some don't.

I sometimes find stty -g helpful in figuring out what the line is
really configured to do, but I'm a little geeky that way.

What does your stty -a output say?  Does it say opost or -opost?
If it's the latter, then there'll be no output processing at all.

What application is using the tty in question, and does it issue any
ioctls?  If so, then all bets with stty may well be off -- applications
can (and very often do!) change anything they want.

The setting you logically want here is opost onlcr -onlret.  I don't
think it's related to your problem, though.

 I've actually modified the forth interpreter to send NL-CR and reassembled 
 the code, so my original problem is solved.  But it bugs me that things don't 
 seem to work properly.  While ttys are not used much now in the wider world, 
 they are still heavily used as the interface to microcontrollers both for 
 interaction and for loading new firmware.  
 
 I'm *very* resistant to having to use Linux for this and simply won't use 
 Windows which is the predominate environment for working w/ microcontrollers. 
  Unfortunately there's a fair bit of open source stuff that doesn't like 
 Solaris :-(  It was a good bit of work to get this far.
 
 In view of the admin overhead, I'll probably defer working on ttymon  
 friends until I can setup a faster OI machine.  Working on OI wasn't actually 
 in my plans at this time.

I think you may well be barking up the wrong tree.  Details on precisely
what software you're using and what you have connected to what via a
serial link would probably be helpful in getting a more useful response.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] Core i7 2600 is being installed as i386

2012-09-05 Thread Handojo
Thanks A lot Jim.

I will note this in case similar incident happens.

BTW, a simple restart, and the system detect as amd64.

I think it is a timing bug on obtaining the string i386 without detecting amd64 
first


2012-09-02 18:50, Handojo пишет:
Hi, I had Core i7 2600 with 16 GB of RAM. After successfully install 
OI151a-5, issuing # isainfo i386 I've been installing on 10+ AMD system 
and get correct kernel ( amd64 ), but this very first time installing on Core 
i7 give me back to i386 Any clue how to fix it ?  It may be possible that 
GRUB misdetects the hardware; while in grub 
menu, try to issue c to edit the boot option and in kernel/module
lines replace $ISADIR with amd64 explicitly. HTH,
//Jim
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Reginald Beardsley
This is an example of one symptom:

oi%rhb {9} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
oi%rhb {10} stty -onlcr
oi%rhb {11} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

Notice that stty did *not* toggle onlcr. As noted earlier, I can toggle olcuc 
and some other output modes, but there are several I can't.

I started checking just the xterm window stty settings when I couldn't get tip 
to do this by setting things in /etc/ttydefs.  It appears to me that something 
is broken in code which is common to stty and ttymon.

I'm using tip running in an xterm to connect to an USB-RS-232 adapter 
connected to an MSP430G2553 installed in a TI MSP430 LaunchPad.  The 'G2553 is 
running a forth interpreter.

The example I gave looks like OBP because OBP is also a forth interpreter. I 
should probably have commented on that previously.  It's not really relevant, 
but could be confusing.

I have two different forth interpreters that run on the MSP430G2553, a 20 pin 
DIP w/ 16K flash  512 byte RAM.  One was sending NL-CR and worked properly.  
The second sent just NL which ttymon  tip *should* be able to convert to NL-CR 
for the display terminal, but did not.

As noted previously, I've now modified the second forth so that it sends NL-CR 
and things work fine for my purposes.

In summary, I'm connecting to a remote host over a serial line. Old and 
obsolete cruft to most these days, but the predominate means of communicating 
w/ microcontrollers today and probably always will be.  It only takes 2 pins, 
Rx  Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU pins 
are very precious. It also doesn't even require a UART in the MCU, though many 
have them.  So *any* MCU w/ 2 free pins can use RS-232 to talk to the outside 
world.

This is what stty  ttymon exist for.  But it doesn't seem to work and appears 
to have been broken for some time as Solaris 10 has the same problem.  Nemeth 
et al note Solaris serial line discipline is a mess.  However, it appears to be 
worse than that.  It appears to be broken.

Have Fun!
Reg


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread James Carlson
Reginald Beardsley wrote:
 This is an example of one symptom:
 
 oi%rhb {9} stty -a | egrep opost
 opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
 oi%rhb {10} stty -onlcr
 oi%rhb {11} stty -a | egrep opost
 opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

You're probably best off just using truss -vioctl to figure out what
those commands are actually doing.  I'll bet that you see a TCGETS with
oflag set to 005 followed by a TCSETSW with oflag set to 001,
showing that stty is in fact attempting to toggle that bit.

Then, when you do stty -a again, oflag is stubbornly set to 005.

The conclusion you can draw from that is that there's nothing at all
wrong with stty -- it's doing precisely what you asked -- and that it's
something else that's being cantankerous.

As an experiment, try this:

stty -onlcr ; stty -a

You may well find that the output is jagged (due to the lack of
onlcr), and that the output includes -onlcr.

The conclusion to draw from that experiment is that you're being
confused by your shell.  The shell itself (on issuing the prompt) is
helpfully setting some sane stty modes for you.

In other words, recompiling stty isn't going to do anything useful.

 I'm using tip running in an xterm to connect to an USB-RS-232 adapter 
 connected to an MSP430G2553 installed in a TI MSP430 LaunchPad.  The 'G2553 
 is running a forth interpreter.

OK.  I expect that the problems you have are related to the behavior of
tip, not of stty.

 The example I gave looks like OBP because OBP is also a forth interpreter. I 
 should probably have commented on that previously.  It's not really relevant, 
 but could be confusing.

It's relevant because that remote system is sending data that is then
copied by tip through the tty to xterm.  Knowing what's going on
necessarily involves knowing precisely what the remote system is
expected to send.

 I have two different forth interpreters that run on the MSP430G2553, a 20 pin 
 DIP w/ 16K flash  512 byte RAM.  One was sending NL-CR and worked properly.  
 The second sent just NL which ttymon  tip *should* be able to convert to 
 NL-CR for the display terminal, but did not.

When you're running tip in the foreground, it's in charge of the modes
on the tty.  stty has very little to do with it.

Looking at the tip source code (usr/src/cmd/tip/), it looks like tip
always puts the tty into raw mode (c_oflag = 0, and c_flag ~ICANON)
when handling data from the remote system.

Thus, that bare NL is going straight to xterm, and it's doing what the
xterm's default VT102-like terminal emulation tells it to do.  If this
is really xterm (and not the GNOME Terminal application or something
else), then setting autolinefeed (accessed by holding the ctrl key and
pressing the middle mouse- button) should fix the problem.

In short, the configuration of the terminal emulator (xterm in this
case) MUST match what the remote system thinks it's talking to.  If it
doesn't, you'll see unfortunate results.

 As noted previously, I've now modified the second forth so that it sends 
 NL-CR and things work fine for my purposes.
 
 In summary, I'm connecting to a remote host over a serial line. Old and 
 obsolete cruft to most these days, but the predominate means of communicating 
 w/ microcontrollers today and probably always will be.  It only takes 2 pins, 
 Rx  Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU 
 pins are very precious. It also doesn't even require a UART in the MCU, 
 though many have them.  So *any* MCU w/ 2 free pins can use RS-232 to talk to 
 the outside world.
 
 This is what stty  ttymon exist for.  But it doesn't seem to work and 
 appears to have been broken for some time as Solaris 10 has the same problem. 
  Nemeth et al note Solaris serial line discipline is a mess.  However, it 
 appears to be worse than that.  It appears to be broken.

I don't think anything at all is wrong with the Solaris line discipline
support.  But those writing books can say whatever they want.  ;-}

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] OpenIndiana lead Alasdair Lumsden resigns

2012-09-05 Thread Bryan N Iotti

Folks,

I got on board the OI boat seriously back in April. I love it. It has 
pushed me to learn a lot about Solaris as an OS and certain technologies 
(like SAS, SCSI) that probably wouldn't have had a place on the Mac I sold.


I want to work with it and use it in solutions I propose to Vet clinics 
and the like.


I am not a programmer (I do some basic Ruby and shell scripting), so I 
wouldn't really know how to help with code, but I'd like to help with 
the website and wiki.


Can I help, and if so, how do I get started?

Bryan


On 09/ 5/12 05:21 AM, Jan Owoc wrote:

On Tue, Sep 4, 2012 at 8:35 PM, Magnus mag...@yonderway.com wrote:

On Sep 4, 2012, at 12:47 PM, Bob Friesenhahn wrote:

I expect that this became available in oi_151a_prestable5 (however, 
oi_151a_prestable6 is out today!).

I'm looking at http://dlc.openindiana.org/isos/ and it looks like 151a5 is the 
latest available to the public right now.

oi_151a_prestable6 AKA oi_151a6 is a bug and security fix release.
This is not an ISO release. [1]
Making an ISO image takes time, so tends to happen every 2-3 releases.
You need to install prestable5 and then upgrade.

[1] http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes



Does this require the end user to do anything special, or should it just work 
when installing OI? Right now some other Illumos distros are not handling these drives 
well at all yet. My drive is coming up as WDC WD2002FAEX-0 revision 1D05.

I don't think the drive's model number or revision will change with a
system update. I don't know whether it detects sector size or simply
uses ashift=12 always (using 4k data sectors on a 512b drive doesn't
exactly have downsides). Either way it shouldn't require any manual
user intervention.

Some drives behave by reporting 4k sectors (not sure about yours
specifically), and then even OI 151a (what I used) created a pool with
ashift=12 when needed.


root@openindiana:~# zdb -C rpool | grep ashift
 ashift: 9
root@openindiana:~# zdb -C tankz2 | grep ashift
 ashift: 12
root@openindiana:~# uname -a
SunOS openindiana 5.11 oi_151a4 i86pc i386 i86pc Solaris


Jan

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] isc-dhcp client

2012-09-05 Thread Gordon Ross
On Wed, Sep 5, 2012 at 11:04 AM, Gary Gendel g...@genashor.com wrote:
 Hi,

 Anyone know if there is a fundamental reason why we can't wholesale replace
 the Sun/Oracle dhcp client with the ISC one?  If we don't get any updates
 downstream from Oracle we will never get features like ipv6 prefix
 delegation.  This feature is becoming important as some big ISPs (i.e.
 Comcast) are using this to delegate IPV6 blocks to their business/personal
 customers.

 If the answer is that I should be able to replace it, the next question is
 if anyone has done this before and how difficult this would be to do.

 Gary

Is there any integration with dhcpmgr available for the ISC dhcpd?

-- 
Gordon Ross g...@nexenta.com
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] sox library mismatch in OI 151a6

2012-09-05 Thread Jon Tibble

On 05/09/2012 18:14, Chad Cantwell wrote:

After upgrading from 151a5 to 151a6, sox stopped working with this error:

$ sox
ld.so.1: sox: fatal: libsox.so.2: open failed: No such file or directory
Killed


I couldn't find libsox.so.2 anywhere, but symlinking libsox.so.1 fixed the
issue for now.

Chad



Hi Chad,

Thanks, a fix is just building now and should be available tomorrow.

JT


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Reginald Beardsley


--- On Wed, 9/5/12, James Carlson carls...@workingcode.com wrote:

 From: James Carlson carls...@workingcode.com
 Subject: Re: [OpenIndiana-discuss] stty source code
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Wednesday, September 5, 2012, 1:26 PM
 Reginald Beardsley wrote:
  This is an example of one symptom:
  
  oi%rhb {9} stty -a | egrep opost
  opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
 
  oi%rhb {10} stty -onlcr
  oi%rhb {11} stty -a | egrep opost
  opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
 

[snip]

 
 As an experiment, try this:
 
     stty -onlcr ; stty -a
 
 You may well find that the output is jagged (due to the lack
 of
 onlcr), and that the output includes -onlcr.

Well, well...

Apparently /bin/tcsh helpfully resets certain of the tty modes.  Can't trust 
a user to know what they need. /bin/sh and /bin/csh behave as expected.

What a staggering waste of time. Command line retrieval and editing is nice, 
but not at this price.

Sigh...
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Reginald Beardsley
Having established that the stty behavior is a  red herring produced by 
/bin/tcsh here is a precis of the situation (pwd is /etc):

oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
 u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
 msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430
oi%rhb {181} pmadm -l
PMTAG  PMTYPE SVCTAG FLGS ID   PMSPECIFIC
zsmon  ttymon tty0   uroot /dev/term/0 b - 
/usr/bin/login - msp430 ldterm,ttcompat login:  - - -  -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0

connected
  ok.
   ok.
ok.
   ~
[EOT]
rhb@openindiana:/etc$ stty -a   
   
speed 38400 baud; 
rows = 77; columns = 107; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
intr = ^c; quit = ^\; erase = ^h; kill = ^u;
eof = ^d; eol = undef; eol2 = undef; swtch = undef;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^?; lnext = ^v;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff 
-parext 
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc 
ixon ixany -ixoff imaxbel 
isig icanon -xcase echo echoe echok -echonl -noflsh 
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten 
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
rhb@openindiana:/etc$ stty olcuc
   
RHB@OPENINDIANA:/ETC$ TIP U0
   
connected
  ok.
   ok.
ok.
   ~
[EOT]
RHB@OPENINDIANA:/ETC$   
Note that I have olcuc onlcr set in ttydefs, but it's not being done.  With 
italso set in the terminal window it doesn't get applied to the remote host 
traffic. (The connect is from the USB adapter)

Communication w/ the remote host is 9600 baud, 8 bits, no parity, one stop bit. 
 The remote host is returning just NL in its output.  

Note: The entries in /etc/remote and /etc/ttydefs are a single line each in 
case they appear differently on receipt.

Suggestions?  Does anyone see anything wrong w/ the ttydefs line?  This is 
precisely what I expect ttydefs  ttymon to fix.  At this point, the only 
explanation I can think of is that only inbound traffic passed to /bin/login 
gets the effect of the arguments in ttydefs and that they are not applied to 
traffic using tip.  If that's the case, it's not broken, it's just brain dead.

Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] stty source code

2012-09-05 Thread Andrew Gabriel

Reginald Beardsley wrote:

Having established that the stty behavior is a  red herring produced by 
/bin/tcsh here is a precis of the situation (pwd is /etc):

oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
  

u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:


===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
  

msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430


oi%rhb {181} pmadm -l
PMTAG  PMTYPE SVCTAG FLGS ID   PMSPECIFIC
zsmon  ttymon tty0   uroot /dev/term/0 b - 
/usr/bin/login - msp430 ldterm,ttcompat login:  - - -  -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0

connected
  ok.
   ok.
ok.
   ~
[EOT]
rhb@openindiana:/etc$ stty -a 


You're running stty on your terminal, not on /dev/term/b.
Try running stty -a  /dev/term/b whilst you have the tip running on it.
(or I'm misunderstanding what you're trying to do.)

--
Andrew

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] VERY slow server performance

2012-09-05 Thread Stuart Shirley
 

Hi - Look for some assistance in improving disk access performance on my
OpenIndiana install.

 

Wanting to upgrade my server based on OpenSolaris and ZFS to 3TB drives, I
upgraded the OS to OpenIndiana 151a.

 

Performance is terrible over the network as compared to the previous
OpenSolaris installation. Hardware is identical with the exception of a
second SATA controller (a second identical  Supermicro AOC-SAT2-MV8) and
additional hard drives.

 

Perhaps related, the USB mouse is virtually none-operational. It will only
update the location of the mouse for about 0.5s out of every 10s. This has
not been an issue, as I usually connect remotely. But still an indication
that all is not well.

 

Transfers on the  machine, from drive to drive appears about the same as
when running under OpenIndiana - but across the networks it's very slow.

 

Moving a large file from my windows 7 machine across the GbE lan - transfers
at ~11.5MB/s as reported by windows copy.

 

Using zpool iostat, the write bandwidth is reported as high as 20M.

 

Now if I run zpool iostat continuously (display every 3 seconds), copy
performance increases - moving into the 16 to 17 MB/s range as reported by
windows.

 

Copying from one storage pool to another, zpool iostat will report write
bandwidths of 26M.

 

 

My pool configuration is detailed below.

 

Other's slow performance had been pegged to flow control enabled on the
Ethernet port - this was disabled. It did make a difference, but not that
dramatic.

 

 

Any suggestions on how to improve performance and how to fix the mouse would
be greatly appreciated!

 

 

Stuart

 

 

 

 

 

 

Flow control properties:

 

LINK PROPERTYPERM VALUE  DEFAULTPOSSIBLE

e1000g0  flowctrlrw   no bi no,tx,rx,bi

 

 

 

 

 

 

Zpool configurations:

 

  pool: rpool

state: ONLINE

  scan: resilvered 4.63G in 0h7m with 0 errors on Wed Jun  6 22:12:16 2012

config:

 

 NAME  STATE READ WRITE CKSUM

 rpool ONLINE   0 0 0

   mirror-0ONLINE   0 0 0

 c3t0d0s0  ONLINE   0 0 0

 c3t1d0s0  ONLINE   0 0 0

 

errors: No known data errors

 

  pool: tank_12T

state: ONLINE

  scan: none requested

config:

 

 NAMESTATE READ WRITE CKSUM

 tank_12TONLINE   0 0 0

   raidz2-0  ONLINE   0 0 0

 c3t7d0  ONLINE   0 0 0

 c3t3d0  ONLINE   0 0 0

 c3t5d0  ONLINE   0 0 0

 c3t6d0  ONLINE   0 0 0

 c5d0ONLINE   0 0 0

 c8d0ONLINE   0 0 0

 

errors: No known data errors

 

  pool: tank_m

state: ONLINE

  scan: none requested

config:

 

 NAMESTATE READ WRITE CKSUM

 tank_m  ONLINE   0 0 0

   mirror-0  ONLINE   0 0 0

 c3t2d0  ONLINE   0 0 0

 c7t6d0  ONLINE   0 0 0

 c6d0ONLINE   0 0 0

   mirror-1  ONLINE   0 0 0

 c3t4d0  ONLINE   0 0 0

 c7t7d0  ONLINE   0 0 0

 c4d0ONLINE   0 0 0

 

errors: No known data errors

 

 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] OpenIndiana lead Alasdair Lumsden resigns

2012-09-05 Thread Bob Friesenhahn

On Tue, 4 Sep 2012, Jan Owoc wrote:


I don't think the drive's model number or revision will change with a
system update. I don't know whether it detects sector size or simply
uses ashift=12 always (using 4k data sectors on a 512b drive doesn't
exactly have downsides). Either way it shouldn't require any manual


There is a downside to using 4k sectors on 512b drives.  Quite a lot 
more space may be wasted because zfs's smallest consumed data size 
(e.g. for metadata) is one sector.  At least two copies are made of 
any metadata.  If you use smaller zfs blocks (than the default 128k) 
and/or a large number of files, you will be wondering what happened to 
your disk space.


For huge drives this is not much of an issue.  It is definitely an 
issue for SSDs, which usually offer much less space per drive.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] isc-dhcp client

2012-09-05 Thread Bob Friesenhahn

On Wed, 5 Sep 2012, Gary Gendel wrote:


Hi,

Anyone know if there is a fundamental reason why we can't wholesale replace 
the Sun/Oracle dhcp client with the ISC one?  If we don't get any updates 
downstream from Oracle we will never get features like ipv6 prefix 
delegation.  This feature is becoming important as some big ISPs (i.e. 
Comcast) are using this to delegate IPV6 blocks to their business/personal 
customers.


If the answer is that I should be able to replace it, the next question is if 
anyone has done this before and how difficult this would be to do.


I assume you are talking about the client and not the server?  If you 
are talking about the client, then it seems possible to do this via an 
upgrade.


If you are talking about the server, unless the ISC version is truely 
a drop-in replacement, it would be best to make it an add-on package 
using different directories so that it is possible to migrate from one 
to the other and not crater users networks due to an update.  As 
Gordon Ross mentions, the Sun dhcp server has nice integration with a 
dhcpmgr GUI (which I use under Solaris 10).


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss