Re: [OpenIndiana-discuss] 32-bit support in OpenIndiana Hipster

[Bruce Lilly]

On Fri, Jan 22, 2016 at 3:00 PM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:

> Hello,
>
> There's something wrong with this picture...
> >
>
> I do not think there is, considering that I was asking about the long term
> goal and not providing a transition recipe to be implemented right away.
>

The problem that I see is that there is neither an organized plan to migrate
to 64-bit-only, nor an effort to take advantage of isaexec support for both
32-bit and 64-bit systems; instead what appears to be a haphazard
piecemeal move to an odd mixture of 32-bit and 64-bit components.

> So if your goal is really to drop 32-bit support (and thereby alienate
> > those with 32-bit systems to support),
> >
>
> I think Alexander raised the concern one year ago and there was barely any
> feedback nor interest in helping.
>

I disagree; I see 6 responses to the original message within a few days,
all expressing an interest in continuation of 32-bit support (for various
reasons), and zero messages encouraging dropping 32-bit support.
The next message after those was today's "official statement"
announcing that 32-bit support is effectively dropped.


> Indeed it would be nice to have someone working on the installer if you
> have an interest in that.


Not much point given the unilateral decision to drop 32-bit support.
Not practical without a well-defined place to find source code for
components in order to be able to work on them.
Given the ready availability of systems (e.g. NetBSD) which do not
have many of the limitations of OI, but which do have thriving user
and developer communities, it's difficult to justify putting effort into
what frankly speaking appears to amount to little more than
flogging a dead horse when a similar effort expended elsewhere
will produce far greater benefit.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] 32-bit support in OpenIndiana Hipster

[Bruce Lilly]

On Fri, Jan 22, 2016 at 2:57 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:

> On 01/22/16 11:32 AM, Bruce Lilly wrote:
>
>> 1. time_t (via illumos; this shouldn't be rocket science -- both NetBSD
>> and
>> OpenBSD have
>>  64-bit time_t on both 32- and 64-bit systems)
>>
>
> OpenBSD made time_t 64-bit with one simple trick: breaking binary
> compatibility.
>

That's not the case for NetBSD.
https://en.wikipedia.org/wiki/Year_2038_problem
gives an overview of both systems as well as others.

Obviously, unilaterally dropping 32-bit support by providing only 64-bit
components also breaks binary compatibility on 32-bit systems, as those
systems are unable to run 64-bit executables or link 64-bit libraries
into 32-bit executables.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] 32-bit support in OpenIndiana Hipster

[Bruce Lilly]

There's something wrong with this picture...

Although OI inherited isaexec and *could* ship both 32- and 64-bit
executables and libraries,
presently only 32-bit libraries are available in many cases (e.g. gamin).
Also, the default
compilation on 64-bit systems produces 32-bit executables (and libraries).

So if your goal is really to drop 32-bit support (and thereby alienate
those with 32-bit
systems to support), you first need to do two things:
1. rebuild all available libraries and executables in 64-bit mode
2. change the default compilation mode for 64-bit systems
The 32-bit time_t issue won't go away until both of those are addressed AND
all existing
64-bit systems have been fully updated (and 32-bit systems replaced).

On the other hand, to properly utilize the attractive feature of
transparently supporting both
32-bit and 64-bit systems via isaexec, and thereby possibly attract (rather
than alienate)
users, two things need to be addressed:
1. time_t (via illumos; this shouldn't be rocket science -- both NetBSD and
OpenBSD have
64-bit time_t on both 32- and 64-bit systems)
2. actually take advantage of isaexec by producing and distributing both
32- and 64-bit
libraries and executables
After those issues are addressed, changing the default compilation mode for
64-bit
systems should be painless (and is expected to provide performance benefits
on
64-bit i86 platforms).
It would also be nice to reduce the (physical) memory requirement,
especially of the OI
installer which uniquely (compared to BSD and most Linux installers)
crashes on
modest-memory (e.g. 512 MB) systems.  Such systems (including low-power
ones)
are fine for many uses which do not themselves require much memory or CPU
power,
such as ntp servers.

On Fri, Jan 22, 2016 at 12:03 PM, Alexander Pyhalov  wrote:

> On 02/16/2015 13:06, Alexander Pyhalov wrote:
>
>> Hello.
>>
>> We currently support (in some way) 32-bit systems. We avoid shipping
>> 64-binaries in default path or use isaexec for such things.
>> But do we really need it? I haven't seen PC (not speaking about server)
>> without 64-bit CPU for at least 8 years.
>>
>> Dropping support for 32-bit systems will allow us to port Oracle sources
>> easier. Potentially, this solves time_t overflow. We could think about
>> largefile support less.
>>
>> What are the cons of keeping support for 32-bit systems? I don't see
>> much. If you see them, please, speak now.
>>
>> I'm inclined to make changes, breaking 32-bit systems only after next
>> ISO snapshot. Of course, 32-bit libraries will be preserved.
>>
>
> Today I've shipped PostgreSQL 9.5. AMD64 version still doesn't have
> PL/Perl support, because we ship 32-bit Perl. The next Perl version which
> we ship will be 64-bit only. I don't think there's much benefit in
> supporting 32bit systems. So, consider this an official statement.
>
> The next OI Hipster snapshot will no pretend to support 32bit CPUS.
>
> --
> Best regards,
> Alexander Pyhalov,
> system administrator of Southern Federal University IT department
>
> ___
> 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] 32-bit support in OpenIndiana Hipster

[Bruce Lilly]

On Fri, Jan 22, 2016 at 3:59 PM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:

> This discussion is actually a call for devising an organized plan !
> So what are you complaining about ?
>

I saw no call for discussion, only an official statement that 32-bit
support is dropped.


> So since there is an interest, let us identify how people showing such
> interest can help out.
>
[...]

> > Not practical without a well-defined place to find source code for
> > components in order to be able to work on them.
> >
>
> You can find the relevant code on OpenIndiana's Github:
>
> https://github.com/OpenIndiana/oi-userland


If the source for the installer is there, it's well-hidden.
More importantly, there is no reference to that Github repository
at http://wiki.openindiana.org/display/oi/Developing+OpenIndiana
which is a link from the main OpenIndiana wiki. [Incidentally,
the most recent entry to the "Developing OpenIndiana" page
is dated 2012].
So how do you expect people to find out about it?


> > Given the ready availability of systems (e.g. NetBSD) which do not
> > have many of the limitations of OI, but which do have thriving user
> > and developer communities, it's difficult to justify putting effort into
> > what frankly speaking appears to amount to little more than
> > flogging a dead horse when a similar effort expended elsewhere
> > will produce far greater benefit.
> >
>
> That's a chicken and egg issue: if everyone is waiting for each other to
> invest time and effor then yes it will surely go nowhere.
> Personally, as I use OpenIndiana and benefit from Alexander's, Ken's,
> Martin's and others work, I try to help out supporting what I use.
> If nobody does and waits for other people to do the job then there is no
> community.
>

It's a very real practical issue.
In my case, I'm looking for an alternative to Linux due to
systemd-induced breakage (e.g. see http://boycottsystemd.org/ ).
I've looked at many alternatives, and the resulting short list was
illumos-based distributions (of which OpenIndiana is representative)
and NetBSD.

NetBSD has most of what I need for general-purpose desktop and
server systems.  The one major thing lacking at the moment is a
decent office suite port. Minor deficiencies include limited support
for hardware sensors (temperature (HDD temperature via SMART
works, but not e.g. motherboard sensors), voltages), and the usual
BSD utility quirks (ps, ls, make; fixable by installing alternatives).

Then there's OpenIndiana.  Won't even install on modest-memory
32-bit systems, installs as 32-bit on modest-memory 64-bit systems
(and is sluggish).  If there's any CPU frequency scaling or power
consumption scaling support, I haven't been able to find it.  No
support for hardware sensors, not even HDD temperature sensors
via SMART on SATA drives (at least not on i86 systems).  Poor FS
support (no working ext2 FS support, for example).  An ancient
version of Xfree86 that doesn't support non-VESA (e.g. large
pixel-count, 16:9 aspect ratio) display resolution/aspect ratio.
Very limited GUI options(basically GNOME, and w/o pkg GUI tool
on "Hipster" [BTW,that name is very off-putting], although it is
possible to have partially-working alternatives (KDE,
Enlightenment, etc) via the Joyent/SmartOS pkgsrc repository
( http://wiki.smartos.org/display/DOC/Installing+pkgin )).
Ancient ("legacy") version of grub.  Syslog appears to lack
RFC 5424 format support.  A number of 32- vs. 64-bit
issues (time_t, library availability, default compilation setting).
In short, a great many things that would need work,
compounded by poor development information (see above).
And I haven't mentioned the learning curves associated
with Solaris-specific stuff (ZFS, zones, boot environments,
svcadm, etc.).

There are many Linux users and developers looking for
alternatives because of the systemd debacle -- where do
you think they will go? [that's a rhetorical question]

Another point: I recently put together some small systems
for educating children (and their parents!) about open-source
computing.  The systems have DoudouLinux  and
NetBSD
installed.  As these are modest-memory systems (fine for
educational use, web browsing, light office suite use, etc.),
OpenIndiana wouldn't install.   So the kids and their parents
will learn about Linux and BSD, but not "genuine UNIX".
Does that (should it) matter to the OpenIndiana project?
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] forum creation

[Bruce Lilly]

On Thu, Feb 26, 2015 at 7:10 PM, Nikola M minik...@gmail.com wrote:

 Well you see, we sort of get used to using ZFS datasets for everyting :)
 I have /export/home/username/.thunderbird as separate dataset and it can
 be used with ZFS
 on: ZFSOnLinux kernel module (all Linux distros, some even have prepared
 packages autocompile and installation), OSX (ZfsOnLinux port), FreeBSD and
 all illumos distros.
 So I can certainly share same Thunderbird profile between all those
 platforms (and Windows if using NFS or SMB share) :)


To support multiple MUAs, you'd have to do that for each one.

And that might be feasible for a single system or a LAN, but won't help if
you're on a public system or somebody else's system.


 As explained, it takes absolutely no additional of local storage
 (especially with ZFS and network exports)
 plus Openindiana has automated self-controlling (one-click enabled) way of
 managing dataset snapshots, (Time slider) that can even take care of
 safeguarding your Mail client profile dir.
 Snapshots in 15 minutes, half hour, hourly, daily, weekly, monthly and
 yearly shapshots, without even attending to it yourself ;)


Each UA stores its own (large) data per UA, per user, per system, so that's
a lot of data.
A separate IMAP server can mitigate that somewhat for MUAs that can use
IMAP, but that doesn't solve the issue of remote access (unless your IMAP
server is publicly accessible).

One of the best ways to read (and search) the archives of this list, from
anywhere with Internet access, is
http://dir.gmane.org/gmane.os.openindiana.general .
Too bad there's no https support (at least not yet).
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] forum creation

[Bruce Lilly]

On Thu, Feb 26, 2015 at 7:31 PM, Nikola M minik...@gmail.com wrote:

 Regarding managing services on Unix-like OSes, illumos and Opensolaris
 descendent OS'es enjoy Service management Facility (SMF), maybe you could
 comment how it stand for you, comparing to other service management ways
 you mentioned? If you have OI installed, you could try it out. (And see if
 it could be improved).


SMF is mostly OK after the usual learning curve.
What's not OK:
1. XML sucks
2. Restarting too quickly seems to happen too frequently for some
services on reboot (usually for services where the daemon forks).
3. Poor support for conversion from init scripts (and XML sucks).
http://wiki.loopback.org/index.php/How_to_add_a_service_to_svc helps, but
XML sucks.

Aha and not to forget, if you do name critical things that seems to be
 ignored, at your opinion,
 I am sure we'll all be much obliged , because that's kind of things that
 are needed to make fire star :)


Some background to keep things in perspective:
I've used mostly System V and System V-like systems for a long time, so
OpenIndiana had an advantage (over e.g. BSD and BSD-like systems with their
peculiar make, peculiar ps, oddball shells, etc.).
A few decades ago, somebody convinced me to try Linux instead of spending
$75 on an OpenSolaris license, so I've been using mostly Linux systems
since then.
After trying a few others, I settled on SuSE, later openSUSE.
Systemd has broken too many things, too many times, and is wasting too much
of my time fixing and re-fixing things that shouldn't have been broken in
the first place; and alternatives (e.g. sysvinit) have been dropped).
The one fast, reliable, stable journaled filesystem previously supported on
openSUSE (viz. Reiserfs) has been dropped.
So it's time to move on.

One issue with OpenIndiana encountered early on is limited networking
driver support; specifically, OpenIndiana has no built-in support for
Marvell yukon series Gigiabit Ethernet.
I was able to find a Solaris driver from Marvell's web site, burn it to
physical media, and sneakernet it; it works, but I wonder whether it will
continue to work for future releases...

Minimum system requirements are unclear; one place says 512MB RAM, another
says 768MB.
I have 4 32-bit (Pentium III, actually) machines which have *very* stable
oscillators serving as NTP servers. They are equipped with the maximum
amount of RAM supported by the motherboard -- 512 MB.
So that's a critical issue (those machines have run Linux (including GUI),
and 3 of the four currently run NetBSD).
I have not found any similarly stable machines to replace those, so they'll
keep running forever as my primary ntp servers.
All four use PPS signals from GPS, so require (and have) real serial ports;
the trend on newer hardware is to abandon real serial ports in favor of
polled once every million-or-so nanoseconds USB with its 57 flavors of
connector variants, and that won't work for PPS.

32-bit and 64-bit issues with OpenIndiana are a major problem.
The 32-bit time_t issue arrives in just a few years (NetBSD has already
solved this on 32- and 64-bit systems).
Some in the OI community seem to be of the opinion that all 32-bit systems
will magically disappear; they won't (see above).
Some seem to be working actively to kill 32-bit support (e.g. on this list
within the past 24 hours!).
Even if 32-bit hardware vanished and 32-bit OS support were dropped, the
issue would remain because the default for building executables -- on
64-bit systems, mind you -- is to produce 32-bit executables.
Even though 64-bit code has performance advantages.
Even though there is support for selecting 32-bit or 64-bit executables at
run-time (isaexec, sometimes called a hack, but it works and being able to
put one ISO disk in 32- or 64-bit systems to load the OS is a nice feature).
Sure, it's possible to force building 64-bit code with -m64 -- but try
linking that code with (for example) the 32-bit only libgamin library; NG.
So to really get 64-bit code, one has to build all needed libraries (and
their dependencies) from source, with -m64; there ought to be a better way.
This was a show-stopper; I need to support 32-bit systems with limited RAM
for critical functions that have to continue to work past January 19, 2038.
And I don't want to have to build every damned library from source to get
64-bit versions on 64-bit systems.

Lack of support for hardware monitoring is another major issue.
The illumos web site lists as a possible project porting lm-sensors.
When I last looked (until just now, and I see it's changed (slightly)),
contributing required a build environment using an unobtainable compiler
and toolchain; so that was a dead end.
So I tried to at least get temperature data from SMART-equipped hard disk
drives.
No port of hddtemp.
smartmontools doesn't work for IDE drives.
smartmontools really doesn't work for SATA drives even though it's claimed
to work (it doesn't because the driver for SATA drives (on 

Re: [OpenIndiana-discuss] forum creation

[Bruce Lilly]

On Tue, Feb 24, 2015 at 3:53 AM, Nikola M minik...@gmail.com wrote:


 You can also download, ungzip , concatenate with cat (cat *.txt  listname)
 and use in Thunderbird as local searchable mailing list archive.
 If you point new mail list messages in that folder in client,  you can
 have full up to date archive.


One can, if one is so inclined.  And repeat the whole process for each user
who wants to read the messages.
And for other MUAs.  And for other OSes, if a multi-boot system.  And on
each separate system on which it is desired to read the messages.
But it's rather inconvenient to do all of that, and it takes a great deal
of local storage.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] forum creation

[Bruce Lilly]

On Tue, Feb 24, 2015 at 3:53 AM, Nikola M minik...@gmail.com wrote:

 If you find other things out of date or not representing current state of
 affairs on the Wiki,
 feel free to post a bug report, comment or request Wiki account if you
 feel you can contribute some content to the Wiki.


It's pretty much everything; for example, just a few clicks from Wiki+Home
gets one to http://wiki.openindiana.org/oi/OpenIndiana+Releases
which would be funny if it weren't so sad (here it is late in the first
quarter of 2015, and the 2011.Q4 release is Pending).

If it looked as though there might be a road map leading somewhere I might
have been more inclined to pursue OpenIndiana as a Linux replacement (must
get away from the systemd debacle), but I couldn't find anything
encouraging, and while there is a lot that looks interesting, there are too
many critical issues that seem to be being ignored, so I'm focusing on
something (viz. NetBSD) that does appear to be moving forward.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] forum creation

[Bruce Lilly]

http://wiki.openindiana.org/oi/Mailing+Lists says:
Read-Only archives

The mailing lists are archived over at Google Groups
http://groups.google.com/

but like many things on the OpenIndiana wiki, that is out of date and
untrue.


There is of course gmane (http://gmane.org/) if somebody wants to set up a
newsgroup and mail-news gateway.

On Mon, Feb 23, 2015 at 2:53 PM, Nikola M minik...@gmail.com wrote:


 On 02/23/15 08:18 PM, Krzysztof Grzempa wrote:

 Maybe it is god idea to have it in a graphical way, but if mailing list

 of doing things is preserved, then there's no objection to Web  
 representation of mailing lists.

 Totally agree. Anyway, correct me if I'm wrong but google groups a a way
 of
 graphical representation of mailing groups. I'm not saying this should be
 migrated there but maybe there is some software which can presents emails
 like that ?

 Maybe something like that is in the line of sight for Mailing list
 representation.
 Of course using Google services for something like that is surely out of
 question,
 but self-hosting software solution is a solution to use, if any is
 recommended.



 ___
 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] 32-bit and/or 64-bit programs (Was: Bash bug issue)

[Bruce Lilly]

On Tue, Nov 11, 2014 at 7:21 AM, Andrew Gabriel 
illu...@cucumber.demon.co.uk wrote

 We currently support 32 bit and 64 bit kernel. A bug fix needs to work on
 both 32 and 64 bit versions, so that would not be acceptable as a bug fix
 for this issue (if it was something you were trying to fix in the distro).


There isn't anything specific in the program in question that would
definitively qualify as a bug.
The program operates correctly e.g. even when compiled as a 32-bit
application on NetBSD:

# file grap
grap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for NetBSD 6.1.5, not stripped
# ./grap -d grap.defines test.grap | grep aligned
line invis 2038-01-20T23:59:59 aligned from Frame.Bottom.end + (0, -0.4)
to Frame.Bottom.start + (0, -0.4)

There are two parts of the problem, neither of which is specific to
application code:
1. 32-bit time_t provided by Solaris-derived kernel, run-time, and build
system is inadequate (well-known, long-standing issue)
2. default build on Solaris-derived 64-bit systems is 32-bits.  Even though
the 64-bit version works as expected on OI, it isn't built as 64-bit
without special effort; i.e. by default anything using time_t is broken,
even on 64-bit OI.

Other OSes (e.g. NetBSD as shown above) have solved issue #1.
If issue #1 is solved on illumos, issue #2 becomes strictly a performance
tweak.
If there's a bug involved here, it is issue #1.

Issue #2 means that without special Solaris-specific effort, applications
using time_t or any library functions that directly or indirectly use
time_t may exhibit anomalous behavior when built for Solaris or illumos,
even on 64-bit systems.

Applications which need to handle dates outside of the operating system
 time (such as dates of births, deaths, marriages, retirements, etc)
 shouldn't be using time_t -- that's very well established.


You have an alternative?
Note that every standard time-based function eventually involves time_t.
That includes strftime() and strptime() as in the example, time(),
clock_gettime(), all of the ctime functions (localtime(), gmtime(), etc.) ,
mktime(), difftime(), and so on.


 Generally, 32 bit apps which are simply rebuilt as 64 bit (without being
 modified to explicitly make use of larger address space) run faster on x86
 because of the extra registers available for compiler optimisation, and run
 slower on sparc because of the larger working set size.


That sounds like a good reason (in addition to the time_t correctness
issue) for making 64-bit builds the default, at least on 64-bit x86.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Bash bug issue

[Bruce Lilly]

On Tue, Nov 4, 2014 at 2:58 AM, Jim Klimov jimkli...@cos.ru wrote:

 On Mon, 3 Nov 2014, Bruce Lilly wrote:
 
  As of this late date, /usr/bin/bash here is in fact the bash
 executable,
  not a link; but that means that it's 32-bit only and might well
 [...]
 So most of the programs (thousands of binaries supplied with a sol10
 distro and extension discs) remained 32-bit only. A minority of the
 lrograms that were deemed to really need this (under 700? or even 100?)
 were dual-built and provided with the isaexec hack to pick the right binary
 at run-time depending on the running kernel (32/64).


One more note applicable to bash before I start a separate thread regarding
32-bit vs. 64 bit issues that aren't bash-specific:

# ls /bin/amd64/*sh /*/bin/amd64/*sh /*/*/bin/amd64/*sh | egrep -v
lish|ush|mash|rash|\.sh|ssh
/bin/amd64/bash
/bin/amd64/ksh
/bin/amd64/rbash
/bin/amd64/rksh
/bin/amd64/tclsh
/bin/amd64/tcsh
/bin/amd64/wish
/bin/amd64/zoomsh
/usr/bin/amd64/bash
/usr/bin/amd64/ksh
/usr/bin/amd64/rbash
/usr/bin/amd64/rksh
/usr/bin/amd64/tclsh
/usr/bin/amd64/tcsh
/usr/bin/amd64/wish
/usr/bin/amd64/zoomsh
/usr/openwin/bin/amd64/bash


/usr/openwin/bin/amd64/ksh


/usr/openwin/bin/amd64/rbash


/usr/openwin/bin/amd64/rksh


/usr/openwin/bin/amd64/tclsh


/usr/openwin/bin/amd64/tcsh


/usr/openwin/bin/amd64/wish


/usr/openwin/bin/amd64/zoomsh


/usr/X/bin/amd64/bash


/usr/X/bin/amd64/ksh


/usr/X/bin/amd64/rbash


/usr/X/bin/amd64/rksh


/usr/X/bin/amd64/tclsh


/usr/X/bin/amd64/tcsh
/usr/X/bin/amd64/wish
/usr/X/bin/amd64/zoomsh
/usr/X11/bin/amd64/bash
/usr/X11/bin/amd64/ksh
/usr/X11/bin/amd64/rbash
/usr/X11/bin/amd64/rksh
/usr/X11/bin/amd64/tclsh
/usr/X11/bin/amd64/tcsh
/usr/X11/bin/amd64/wish
/usr/X11/bin/amd64/zoomsh
/usr/X11R6/bin/amd64/bash
/usr/X11R6/bin/amd64/ksh
/usr/X11R6/bin/amd64/rbash
/usr/X11R6/bin/amd64/rksh
/usr/X11R6/bin/amd64/tclsh
/usr/X11R6/bin/amd64/tcsh
/usr/X11R6/bin/amd64/wish
/usr/X11R6/bin/amd64/zoomsh

Evidently there are quite a few shells -- N.B. including bash -- where the
packagers seem to have decided there were issues warranting building and
packaging 64-bit versions.

I'll let somebody else figure out exactly why the recent updated version of
/usr/bin/bash trampled on the isaexec pointing to separate 32- and 64-bit
versions; I don't really care much about bash per se as I don't use it (for
reasons having to do with familiarity, usability, portability, and
reliability; before shellshock added security to that list).
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] 32-bit and/or 64-bit programs (Was: Bash bug issue)

[Bruce Lilly]

A while back, there was a suggestion made to build bash from updated
sources (patched for variations of the shellshock vulnerabilities),
simply mv /usr/bin/bash to another name and install a link to the newly
built program.

I pointed out that this might not be a good idea without first carefully
checking to make sure that /usr/bin/bash wasn't simply a copy of or link to
/usr/lib/isaexec as described in
https://docs.oracle.com/cd/E18752_01/html/816-5138/docinfo.html (Solaris
64-bit Developer's Guide).

Other UNIX-like systems that support both 32-bit and 64-bit versions
typically default to building 64-bit executables on 64-bit systems and do
not provide the isaexec mechanism to select executables.  Regardless of the
merits or lack thereof of either approach, the Solaris default of always
building 32-bit executables *only* is a deep dank pit in a poorly lit
corner of Solaris and Solaris-like systems that is likely to trap many
folks, particularly those coming from other backgrounds, and even
experienced developers porting source packages.  It isn't mentioned in any
of the places that promote building from sources (So Jim, how about
updating
http://wiki.illumos.org/display/illumos/Building+illumos+and+OpenIndiana
?), nor in Red Hat Enterprise Linux to Oracle Solaris Porting Guide
http://www.oracle.com/technetwork/server-storage/solaris11/documentation/o12-026-linux2solaris-guide-1686620.pdf
.

I mentioned that the 64-bit Developer's Guide is a bit dated: I say that
because the sole example of time_t-related issues mentioned there is
mortgages.  I suspect that few mortgage calculations are done using integer
arithmetic using time_t...  There are more ubiquitous uses of time_t, such
as:
1. ntp
2. expiration dates for certificates
3. any programs reliant on time synchronization (all version control
systems, rsync, etc.)
4. as a trivial example, lowly 'ls' needs to be able to deal with time_t to
display file modification times.

And there is not yet any good solution to the problem (see e.g. the
Wikipedia page for Year 2038 problem).

Some of the above issues are intersecting: see
https://bugs.ntp.org/show_bug.cgi?id=2651
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Bash bug issue

[Bruce Lilly]

On Sat, Oct 4, 2014 at 11:05 AM, cpforum cpfo...@orange.fr wrote:


 cd /usr/bin

 mv bash bash-oi_151a9

 ln -s /usr/local/bin/bash bash


While that would be reasonable under many operating systems, it *may*
present problems on Solaris-derived systems, especially 64-bit systems.
See http://docs.oracle.com/cd/E18752_01/html/816-5138/index.html (a bit
dated w.r.t. compiler flags, but the principles are still valid, as is most
of the content).
Note in particular that /usr/bin/bash *might* very well be a hard link to
/usr/lib/isaexec and that the real executables *might* live under
/usr/bin/i86pc and /usr/bin/amd64 (on i86 hardware of course).

It would be prudent to check first before moving and/or linking files in
/bin, /usr/bin, /usr/sbin, /usr/lib, ...

Actual conditions depend on whether or not the packager paid any attention
to 32-bit vs. 64-bit issues, and isn't bash-specific.

As of this late date, /usr/bin/bash here is in fact the bash executable,
not a link; but that means that it's 32-bit only and might well present
unexpected issues on 64-bit systems when dealing with large files etc.
(basically anything that involves pointers, long integers, time_t,
ptrdiff_t, clock_t, dev_t, off_t, size_t, or ssize_t in the sources).

If you are building from source on a 64-bit system, I strongly recommend
reading that document.

Note that for ksh, the situation described in the 64-bit Solaris
Developer's Guide applies:
#: isainfo -v
64-bit amd64 applications
cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
#: ls -l /bin/ksh* /usr/bin/ksh* /bin/*/ksh* /usr/bin/*/ksh*
/usr/lib/isaexec
-r-xr-xr-x  4 root bin 9712 2013-07-21 10:35 /bin/amd64/ksh
-r-xr-xr-x  4 root bin 9712 2013-07-21 10:35 /bin/amd64/ksh93
-r-xr-xr-x  4 root bin 8064 2013-07-21 10:35 /bin/i86/ksh
-r-xr-xr-x  4 root bin 8064 2013-07-21 10:35 /bin/i86/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /bin/ksh
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /bin/ksh93
-r-xr-xr-x  4 root bin 9712 2013-07-21 10:35 /usr/bin/amd64/ksh
-r-xr-xr-x  4 root bin 9712 2013-07-21 10:35 /usr/bin/amd64/ksh93
-r-xr-xr-x  4 root bin 8064 2013-07-21 10:35 /usr/bin/i86/ksh
-r-xr-xr-x  4 root bin 8064 2013-07-21 10:35 /usr/bin/i86/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/bin/ksh
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/bin/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/lib/isaexec

This topic appears not to be addressed adequately on the OpenIndiana wiki
(certainly no mention under Compiling+software+on+OpenIndiana) or the
illumos site (certainly no mention under Building+illumos+and+OpenIndiana
there).  It seems to be something one either knows about or not (I stumbled
upon it while researching why uname -m and uname -p returns the same values
on 32-bit and 64-bit installations (and is therefore useless in determining
whether the installation is 32- or 64-bit), and why all of the executables
in /bin (etc) are 32-bit applications on my 64-bit systems, and why all
executables built on my 64-bit systems are 32-bit executables when built
using default compilation flags -- all of those being unexpected).
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Bash bug issue

[Bruce Lilly]

 So, do you mean that ksh93 does not have the vulnerability?

http://lists.research.att.com/pipermail/ast-developers/2014q3/003964.html

On Tue, Sep 30, 2014 at 10:02 AM, Bob Friesenhahn 
bfrie...@simple.dallas.tx.us wrote:

 On Tue, 30 Sep 2014, Jim Klimov wrote:


 Maybe a stupid question on my side (sorry i'm overwhelmed with relocation
 and other life events), but how really is this bug exploitable? Especially
 on Solaris and illumos systems with sh/ksh by default and assumed no
 scripted CGI (hosts of native or java sourced web-code though) ?


 It is readily exploitable for web CGI scripts which provide/export values
 provided by the web server and remote client as environment variables.  The
 CGI paradigm has thoroughly permiated web application infrastructures.
 The exploit requires that bash be executed with the problematic environment
 variables already set. Service applications obtained from Linux often
 require bash in order to run.

 On my own systems, the only service I found which was suspect was 'git'
 and 'gitweb.cgi' since the 'git' implementation depends on many shell
 scripts, which specifically depend on bash.

 For example, this is output from the test-cgi script provided with Apache:

 CGI/1.0 test script report:

 argc is 0. argv is .

 SERVER_SOFTWARE = Apache/2.0.63 (Unix) DAV/2
 SERVER_NAME = www.simplesystems.org
 GATEWAY_INTERFACE = CGI/1.1
 SERVER_PROTOCOL = HTTP/1.1
 SERVER_PORT = 80
 REQUEST_METHOD = GET
 HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,*/*;
 q=0.8
 PATH_INFO =
 PATH_TRANSLATED =
 SCRIPT_NAME = /cgi-bin/test-cgi
 QUERY_STRING =
 REMOTE_HOST =
 REMOTE_ADDR = 65.66.245.66
 REMOTE_USER =
 AUTH_TYPE =
 CONTENT_TYPE =
 CONTENT_LENGTH =

 and this is output from a Perl script called 'printenv' which prints
 everything made available:

 DOCUMENT_ROOT=/html
 GATEWAY_INTERFACE=CGI/1.1
 HTTP_ACCEPT=text/html,application/xhtml+xml,
 application/xml;q=0.9,*/*;q=0.8
 HTTP_ACCEPT_ENCODING=gzip, deflate
 HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.5
 HTTP_CONNECTION=keep-alive
 HTTP_HOST=www.simplesystems.org
 HTTP_USER_AGENT=Mozilla/5.0 (X11; SunOS i86pc; rv:30.0) Gecko/20100101
 Firefox/30.0
 PATH=/usr/sbin:/usr/bin
 QUERY_STRING=
 REMOTE_ADDR=65.66.245.66
 REMOTE_PORT=53877
 REQUEST_METHOD=GET
 REQUEST_URI=/cgi-bin/printenv
 SCRIPT_FILENAME=/var/apache2/cgi-bin/printenv
 SCRIPT_NAME=/cgi-bin/printenv
 SERVER_ADDR=65.66.246.89
 SERVER_ADMIN=webma...@simplesystems.org
 SERVER_NAME=www.simplesystems.org
 SERVER_PORT=80
 SERVER_PROTOCOL=HTTP/1.1
 SERVER_SIGNATURE=addressApache/2.0.63 (Unix) DAV/2 Server at
 www.simplesystems.org Port 80/address\n
 SERVER_SOFTWARE=Apache/2.0.63 (Unix) DAV/2
 TZ=US/Central
 UNIQUE_ID=rExdoEFC9koAAEJpoxgJ

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

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

Re: [OpenIndiana-discuss] VNC connections to Hipster

[Bruce Lilly]

Different setup here (oi_151a8 (not hipster), openSUSE clients, had
different error message from Remmina before failure (Selected Security
Scheme 18)).
vncviewer (part of the tightvnc package on the openSUSE client side)
works file.  GNOME client (vinagre) fails. KDE client (krdc) just shows a
dark cyan background.  Remmina fails with a popup error message as noted
above with mostly default settings, but works if the connection is edited
by checking the Disable encryption checkbox on the Remmina side.

So, some things to try in your situation:
1. try different clients on your Ubuntu box(es) [tightvnc's vncviewer is
basic, but if it works that indicates a Remmina issue]
2. try Remmina options, especially related to encryption.
3. check if your install wiped out anything that you used to have on the OI
box (e.g. detailed GNOME preferences for desktop sharing (one of the
  nondescript icons on the top panel) for the user that has the GNOME
session open).


On Mon, Aug 25, 2014 at 4:18 AM, Dave Koelmeyer 
dave.koelme...@davekoelmeyer.co.nz wrote:

 Hi Folks,

 Before I go delving into why, has anyone else encountered issues with
 using Remmina (on Ubuntu) to connect over VNC to Hipster? On my old
 oi_151a8 box one simply enabled the VNC server in Gnome (/Preferences -
 Desktop Sharing/), pointed Remmina to it without any special sauce and it
 just worked. On my Hipster box (installed using the latest Hipster ISO and
 updated via the current Hipster repository), attempting the same spits out
 an error: /TLS handshake failed: A TLS packet with unexpected length was
 received/. Doesn't appear to be the client either, based on seeing the
 same thing irrespective of which Ubuntu box I connect from.

 Is anyone else seeing this?

 --
 Dave Koelmeyer
 http://blog.davekoelmeyer.co.nz

 ___
 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] Locating source, patches, and build information for binary packages

[Bruce Lilly]

On Tue, Aug 19, 2014 at 1:33 AM, Alexander Pyhalov a...@rsu.ru wrote:


 Hello. ntp sources for /dev package is here - https://hg.openindiana.org/
 sustaining/oi_151a/sfw-gate/file/702bbe36863b/usr/src/cmd/ntpd .
 It comes from SFW consolidation. Information about building different
 consolidations can be found here - http://wiki.openindiana.org/
 oi/Legacy+Consolidations and on child pages. Source code for OI /dev is
 available at http://hg.openindiana.org/ .


Thanks.  I'm new to OpenIndiana, so it will take me a while to digest that.

Incidentally the link to sfw Build instructions on
http://wiki.openindiana.org/oi/Legacy+Consolidations , like many links
in the OI wiki and elsewhere simply dumps to a generic Oracle page.
 Closest thing I can find there is a 7-year
old blog https://blogs.oracle.com/jyrivirkki/entry/how_to_contribute_to_sfw
which gives a link in the text to the
same URL that dumps to the generic Oracle page.  Thank goodness for the
Wayback Machine:
https://web.archive.org/web/20100805034650/http://hub.opensolaris.org/bin/view/Project+sfwnv/install_quickstart
actually looks useful.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] Locating source, patches, and build information for binary packages

[Bruce Lilly]

Could somebody kindly direct me to some resources for locating source and
information about builds of open-source software provided as binary
packages in OpenIndiana.

I suspect this will be a recurring issue; at the moment I'm looking for ntp.

The openindiana package identifies itself (via ntpq -c rv\ 0) as
version=ntpd 4.2.5p200@1.1948-o Fri Jul 12 13:18:04 BST 2013 (1),

Several issues:
1. ntp builds are highly configurable; in addition to the source code, I
will need to know about configuration information for the build, as that
affects (e.g.) which reference clock drivers were included/excluded in the
build.
2. even knowing specified configure script parameters isn't sufficient,
as some things are determined by configure when it runs; these can be
determined by rummaging around in a config.log -- if it's available.
 Building has its own set of dependencies separate from the binary package
installation dependencies that are handled by the package manager -- little
things like whether or not the separate package (!?!) containing math.h
is installed...  If applicable, some hints about choice of build tools
would be nice (make vs. gmake, gcc vs. other compiler, etc.).
3. in order to recreate binaries from (possibly locally-patched) source, I
would also need any source and/or packaging script patches that were used
for the build, but that weren't fed back upstream, if any.

Further information specifically about ntp: I'm going to try to build the
current stable sources (4.2.5 was a development branch): first as
distributed by NTP upstream (with any necessary source/packaging packages),
then with some local patches (https://bugs.ntp.org/show_bug.cgi?id=2346
among others).

Thanks in advance.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss