Re: [OpenIndiana-discuss] Firefox 32bit future

[James Carlson via openindiana-discuss]

On 02/01/2018 11:58 AM, Al Slater wrote:
> On 25/01/18 18:57, Alan Coopersmith wrote:
>> Of course, with the elimination of Netscape plugin support, there's little
>> reason to still use a 32-bit version of Firefox.
> 
> Apart from the fact that 32bit versions die before gobbling *all* of
> your system RAM.  I find this "feature" very useful!
> 

I suggest using "ulimit -v" or, if you want to get really fancy,
"newtask" with a project configured to have the specific resource
controls you want.

I don't think that compilation model is a good proxy for resource
limits.  It's too blunt, and has too many unnecessary side-effects.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] recompiling a program for openindiana

[James Carlson via openindiana-discuss]

On 11/20/17 04:51, Marc Lobelle wrote:
> Hum, this means that bcrypt will not erase the original file after
> encrypying it either and the file must be decrypted to be used. How can
> I make sure that its contents cannot be recovered on zfs then ? (apart
> from writing the zfs encryption code that is missing in illumos zfs ; it
> will have to be done eventually but I'm looking for an interim solution).

This doesn't work on ZFS, and just doesn't work in general even without
ZFS.  It's not uncommon that hardware itself remaps sectors, potentially
leaving sensitive data in place and inaccessible to software that just
goes through the file system layer, but relatively easily recoverable by
an attacker.

The better answer, assuming physical security is insufficient, is to
avoid writing sensitive information in the first place: encrypt the data
before writing or configure the file system itself to encrypt.

A quick google search on "zfs secure delete" will turn up all sorts of
discussions about this.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] Boot failure on Hipster upgrade

[James Carlson via openindiana-discuss]

On 09/20/17 17:15, Gary Mills wrote:
> What would have caused this behavior?  What can I do now to enable the
> upgrade to work, or even to debug the problem further?

It's been a while since I debugged a Solaris boot hang, but the basic
scheme is to boot with kmdb enabled (-k on the kernel's command line;
possibly the "$multiboot" line in GRUB), then break into the debugger
using, I think, F1-A (hold F1 and press "A" key) or Shift-Pause/Break.
Once in the debugger, you can do $c to find out where you are right now,
and ::threadlist to print out the state of all of the kernel threads.

If you're lucky, it's obvious.  Often it's not, because there's a state
machine somewhere that's stuck, and there's no visible thread doing
anything with the stuck part.  But it's worth a try.

To do more than that requires staring at the source code and getting
practice with mdb dcmds.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] zpool on the second partition of an external disk

[James Carlson via openindiana-discuss]

On 09/08/17 10:45, Andrew Gabriel wrote:
> On x86, p0 is the whole disk, and p1-4 are the 4 primary FDISK partitions.

I should mind my p's and s's.  Thanks, Andrew; you're right.  I was
thinking of s2, not p2.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] zpool on the second partition of an external disk

[James Carlson via openindiana-discuss]

On 09/07/17 16:50, Apostolos Syropoulos via openindiana-discuss wrote:
> 
>> Ok, but what is the problem?
>> What is the output and stderr of your zpool create cXtYdZp2 command?
>> Does it gives any error?
> 
> After more searching I concluded that the command should be
> # zpool create -f utank c13t0d0s2
> 
> The logical Node was  /dev/rdsk/c13t0d0p0and format --> partition --> print 
> showed that slice 2 is the one where I can store data. 
> I have also used fdisk to delete all partitions and thenparted to create the 
> NTFS partition. In order to create thefile system I have used  
> # zfs create utank/External  #chown -R user:group /utank/External
> 
> Now I can use the partition!

p2 is, by convention, "whole disk" when using old-style partitioning.
If you're using that and you've partitioned the disk, I think you've
trashed your NTFS partition or (worse) you have an overlap.

Are you sure?  What exactly does "format" say about the partition map?

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] UBS NIC?

[James Carlson via openindiana-discuss]

On 08/29/17 10:45, Michal Nowak wrote:
> Older, 100 Mbps USB NICs are supposed to work. I have an unsupported Atheros 
> on board NIC, so I bought HEXIN USB 2.0 10Mb 100Mbps IEEE802.3x Asix AX88772B 
> Ethernet Lan Network Adapter on eBay, but I never made it working, not even 
> on Linux. Perhaps a faulty device, but I eventually gave up. You may be more 
> lucky with a PCI NIC. Or return the mainboard to the shop, if possible?

Second the recommendation to get a PCI-based network interface.  Even if
you can get the USB-based one to work, it'll be slow enough that you'll
wish you'd opted for the PCI card.  And the prices are pretty much the
same these days.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] PROBLEM with: [OpenIndiana/oi-userland] support intl API . Some Thunderbird AddOns need this. e.g. Enigmail . (#3441)

[James Carlson via openindiana-discuss]

On 08/22/17 03:15, Predrag Zečević - Technical Support Analyst wrote:
> On 08/22/17 08:59, Alexander Pyhalov wrote:
>> On 08/22/17 09:55 AM, Predrag Zečević - Technical Support Analyst wrote:
>>> Hi all,
>>>
>>> change made in changeset (see attached mail), made TB unusable: it
>>> dumps core with existing configuration:
>>> -rw---  1 rootroot  288M Aug 22 08:42
>>> core.thunderbird.4187
>>
>> Hi, can you send stack trace?
> 
> 
> Hi AlP,
> 
> you mean output from truss (do you want special switchees, beside -f?)
> or core file?
> In both cases, files are big - can you suggest way to transfer and to
> where?

This ought to do the job:

  pstack core.thunderbird.4187

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] mbuffer connection refused on varius ports ... what to try

[James Carlson via openindiana-discuss]

On 03/27/17 04:40, Harry Putnam wrote:
> My rendition:
> 
> zfs send p0/vb/vm@170326_1 |tamp|mbuffer -s 128k -m1000m -0
> recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
> zfs recv -vF p0/vb/vm

That makes no sense at all.  The mbuffer utility doesn't produce usable
output on stdout when given a host name to connect to, and doesn't read
from stdin when given a port number.  So piping from one to the other is
confounding.  And running both on one host isn't logical.  I don't see
what you're trying to do there.

If you plan to use mbuffer between two systems, you have to run the
receiver on one host, and the sender on the other.

Start the receiver first.

If you see "connection refused" warnings, then it's time to start
looking at:

  - Is the port actually open on the receiver's side when the mbuffer
utility?  Use "netstat -na" to look for it on the receiver after
starting up mbuffer on that system.

  - Are you actually connecting to the host you think you are?  Make
sure that "recv-host" actually resolves to a valid IP address on
the receiving system, as viewed by the sender.  Typing
"host recv-host" on the sender's side can help confirm that.

This sounds like either a usage error or a configuration problem.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] Unconscious until the end of the project the continuation of OpenSolaris

[James Carlson via openindiana-discuss]

On 03/11/17 14:38, Will Brokenbourgh wrote:
> On 03/11/17 09:33, Илья Архипкин wrote:
>> Breaks any Chinese man about it you can talk a lot I so understood Amrika
>> is a great Nigerian hamburger
>> With Coca-Cola and gaskets Olweis for more simply no one is capable
>> only of
>> migrants
>>
> Wondering what a 'Nigerian hamburger' looks like... :-P

Wonder no more:

http://www.nigerianfoodtv.com/2013/05/homemade-burger-in-pan-patties-made.html

OK ... now I'm hungry.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] thunderbird writes cores

[James Carlson via openindiana-discuss]

On 02/27/17 07:56, Carsten Grzemba wrote:
> My thunderbird 45.6.0 on hipster writes core files, but the stack is not 
> clear for me:
> 
> fef01035 __pollsys (8046b20, 1, 0, 0, fe69fb90, 8046c20) + 15
>  fee92f36 poll (8046b20, 1, , feef51b6) + 66
>  f915a705 _xcb_conn_wait (fe665000, 8046be0, 0, 0) + 95
>  f915c740 wait_for_reply (1075d, 0, 8046ca4, f9596000, fe656000, fe656000) + 
> f0
>  f915cac5 xcb_wait_for_reply64 (fe665000, 1075d, 0, 8046ca4, fe66500c, 
> 8046ca4) 
> + 55
>  f94a3f3f _XReply (fe656000, 8046d00, 0, 1, fe656000, 1) + 1af
>  f21a1737 XScreenSaverQueryInfo (fe656000, 100, e43f8160, fc7daf42, f1ecdb8c, 
> 0)
>  + 87
>  fc7daf4a  (8109, 11945c3, 3cec8300, 8b08758b, ac83, fc08500)
>  ace85356  ()
> 
> Why is TB interested in my screensaver? 

That call (XScreenSaverQueryInfo) will tell you whether the screen is
currently being displayed and how long until it will go to the saver (if
displayed) or how long it's been in screen-saver mode (if not displayed).

My guess would be that they're using this information to determine
whether or not to scan for new email.  Why bother pulling data via POP
or IMAP if the screen isn't being displayed at all?  Especially since
most users leave their email client up all the time.

> What is so terrible on my screensaver that TB cores?

That's probably the right question.  But I don't see a reason for a core
dump here.  Are you sure that's the thread that faulted?

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard

[James Carlson via openindiana-discuss]

On 01/24/17 14:45, Tim Mooney wrote:
> While testing and debugging, we also discovered that some of the
> list speculation from earlier in the thread turned out to be correct:
> we could pacify the Cisco switch if I set the following two ARP-related
> tunables:
> 
> sudo ndd -set /dev/arp arp_defend_interval 2
> sudo ndd -set /dev/arp arp_defend_rate 360
> 
> For whatever reason, making OI gratuitously ARP more frequently than every
> minute (we chose every 20 seconds) was enough to make the Cisco switch
> keep its device map up to date.

Yikes!  Thanks for sharing the information.  This is likely to be
something that other people will run into.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard

[James Carlson via openindiana-discuss]

On 01/05/17 18:49, Tim Mooney wrote:
> In regard to: Re: [OpenIndiana-discuss] arp response tuning for IP
> Source...:
>> It would be great to see the syslog messages and (if possible) a packet
>> trace showing what's going on.  In general, if the system itself is
>> directly responsible for these outages, it will at least log something
>> about the event.
> 
> At the log level I've been running at, there hasn't been anything useful
> logged related to this.  If necessary, I can definitely dial up the
> logging.

If the system were taking any action to take down the interfaces and
defend itself from attack on the network, that would be logged.  If
you're really not seeing log messages, I don't think the system is doing
that.

>> Are these ARP requests or responses?  There are subtle differences
>> between the two.
> 
> According to our principal network engineer, the Cisco switch was
> defaulting to sending 3 ARP probes (in quick succession) every 60
> seconds.  He has since dialed that back to just 1 per 60 seconds
> for this particular switch, to see if that had any impact on the
> issue, but it did not.

There's nothing about an "ARP probe" (if that's truly what they're
sending) that could cause such a problem, at least as far as I know.

It's hard to give any sort of definitive (or even helpful) answers
without seeing the actual packets and error messages.

> He's done a bunch more research since I sent my initial question to
> this list, and right now he thinks the issue may be that the ARP probe
> from the Cisco switch is unicast, but Solaris apparently may be issuing
> ARP responses as *broadcast*, which the switch may not be expecting.

The response may be unicast or broadcast.  It depends on the context.

In general, if we haven't replied to a query in a "long time," then it's
possible that some conflicting IP address has been introduced on the
network.  To guard against that, we deliberately broadcast our reply in
an attempt to ferret out that interloper.

If we've responded recently or have actively defended our address
recently, then the response is unicast.

Per the standards, the Cisco box should process both unicast and
broadcast messages.

See section 2.6 in RFC 5227 for more about the issues.

> The reference he found related to broadcast ARP responses is here:
> 
> http://seclists.org/nmap-dev/2009/q1/176
> http://unix.derkeiler.com/Mailing-Lists/SunManagers/2009-01/msg00015.html
> 
> 
> He's also suggested that I might be able to set 'arp_defend_interval'
> to something like 20 seconds, so that my workstation just periodically
> sends unsolicited ARPs for itself, to essentially preempt the switch's
> probes.  Based on the docs he found:
> 
> http://docs.oracle.com/cd/E36784_01/html/E36845/gnogz.html

That might work.  But I don't know what the Cisco box is doing or what
traffic is actually on the network.

If broadcast has anything to do with the problem, I doubt that'll help.
We broadcast when we defend our address.  On purpose.  It's how you
update corrupted ARP caches held by other nodes on the network.

> Since the docs say "Never" in answer to the "When to change" for any of
> these settings, I haven't actually tried setting arp_defend_interval.
> The way I read the docs, it seems like arp_publish_interval might be
> better, but I know better than to argue with our principal network
> engineer about anything network related.  :-)

I think it's extraordinarily unlikely that tweaking these things will
help anyone on any reasonable network.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard

[James Carlson via openindiana-discuss]

On 01/06/17 08:17, Doug Hughes wrote:
> It seems to me that you might be hitting up against "arp_defend_rate"
> which by default says that the maximum arps it should be expecting in
> one hour is 100. It's he's sending 3 per minute, that's already 180. I
> could be wrong. I'd probably try setting that to 300 and confirm what's
> going on by using "snoop arp" and then focussing in on the mac address
> of the switch and seeing how many are coming in an hour.

I doubt that, unless the Cisco device is unusually cruel and stupid.  :-/

The "defend rate" is the rate at which the system will defend itself
against active attacks -- that is, if some other system on the network
is claiming to own the Solaris machine's IP address, then the Solaris
machine will defend its ownership of the address up to that rate.

The point of the limitation is to avoid melting the network.  If the
Solaris box is configured on the same broadcast network with a "stupid"
host that insists that it owns the same IP address, then it's better for
everyone involved if the Solaris box just backs down and slinks into a
corner rather than rapidly spewing broadcast messages in an attempt to
assert its dominance.  You can never really dominate an idiot (as, well,
we've all learned recently ...).

Nobody should be challenging the system in that way.  The act of doing
so would by itself poison nodes on the same network by corrupting ARP
caches.  The defense mechanism tries to flush unintentional corruption
away by sending multiple broadcast Reply messages, but there's no
perfect way to fix the problem.  So, if that's what Cisco is really
doing, it would at least be cruel, and I don't normally think that of them.

That's why I wanted to see a packet trace and/or error messages.

You can read more about the topic here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.7917=rep1=pdf

or by googling "Solaris duplicate address detection."

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard

[James Carlson via openindiana-discuss]

On 01/05/17 15:37, Tim Mooney wrote:
> When that was enabled for the subnet I'm on, my hipster workstation and
> the hipster VirtualBox VM I have both started experiencing packet loss.
> Talking with the network engineers, the Cisco switch is sending batches
> of 3 ARP probes periodically, and both my workstation and the VM appear
> to be periodically not responding to the ARP probes.  That causes the
> switch to temporarily ban/block packets from either system, which is
> what's causing the intermittent packet loss.
> 
> Anyone have any suggestions for what tuning I should be looking at
> that would tell the Illumos network stack that it's OK to respond to
> semi-frequent batches of ARP probes?

It would be great to see the syslog messages and (if possible) a packet
trace showing what's going on.  In general, if the system itself is
directly responsible for these outages, it will at least log something
about the event.

Are these ARP requests or responses?  There are subtle differences
between the two.

Based on what I remember from working on this code many years ago, one
of the really confusing bits to deal with is Ethernet bridge ("switch")
behavior itself.  Many bridges (I think at least Extreme, and probably
others) have special mechanisms built-in to protect against ARP storms,
and they rate-limit based on the number of broadcasts.  This is (I
believe!) independent of any sort of "Source Guard" feature.  I ran into
this issue numerous times when testing Solaris IP Duplicate Address
Detection.

It's also possible that it's something else -- such as a driver issue.

-- 
James Carlson 42.703N 71.076W 

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

Re: [OpenIndiana-discuss] How many versions of libs/apps should OI provide?

[James Carlson via openindiana-discuss]

On 12/29/16 17:24, Jim Klimov wrote:
> 29 декабря 2016 г. 22:25:23 CET, Bob Friesenhahn 
> <bfrie...@simple.dallas.tx.us> пишет:
>> On Thu, 29 Dec 2016, James Carlson via openindiana-discuss wrote:
>>> Now we deliver a new libfoo.so.2.  The guy who maintains our
>> application
>>> is a real go-getter, so he relinks and redelivers binaries almost
>> right
>>> away.  When the application runs, it pulls in libfoo.so.2 and (via
>> the
>>> libbar.so.1 dependency) pulls in libfoo.so.1 as well.  Oops.  Chaos
>>> ensues.  You get SIGBUS and an extremely confusing to examine core
>> dump
>>> if you're lucky, or silently corrupted user data if you're not.
>>
>> At least Linux supports versioned symbols and libjpeg (and some 
>> others) were adapted to use versioned symbols so that multiple major 
>> versions of the library could be pulled in at once without harm.
>>
>> Does Illumos support Linux-style versioned symbols?
>>
>> Bob
> 
> Bob, do you mean symbols like 'this requires SUNW_1.23'? Yes, these are here 
> too. I believe they do not quite work around the issue James describes, e.g. 
> when your running binary pulls two copies of different libjpeg.so.* even with 
> proper versioning. For example, if a library uses some global variables for 
> state-keeping, and you call a random set of functions from one and another 
> copy of the loaded lib that both satisfy your older required ABI version, you 
> can get chaos. @James, is this a correct interpretation? ;)

That's close.  The problems are many and end up being complex because
you can't rename the entire Universe.

One way that things go south is by having objects shared in some way
between the variants.  This can happen by (for example) having the
application allocate an object of type Foo.1, and then handing it to a
library that is bound to something using Foo.2.  Unlike some
environments (such as Java), there's no run-time type validation in the
binary world.  In short, if anything other than integral types get
passed around, there's the hazard that passer and passee disagree on
version.

Another way things can go wrong is with external resources, such as
files (particularly, but not limited to, lock files), shared memory
segments, and network connections.  It's not uncommon that a library
"assumes" that it is the only instance of itself within a given process,
and it's shocking when there are duplicates that shift the sand below.

It's possible that a sweeping rename might well have helped with the
libresolv.so.2 problem (if I recall enough of the failures correctly),
but I don't think it's a robust answer.  The robust answer is just never
breaking compatibility, which requires a nontrivial amount of
engineering effort.  (Part of which, naturally enough, goes into the
initial creation of interfaces that aren't so crappy that they need to
be broken in the future.)

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

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