Re: [OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

2012-08-09 Thread Frank Lahm
2012/8/10 Gordon Ross :
> On Thu, Aug 9, 2012 at 11:56 PM, Frank Lahm  wrote:
>> 2012/8/10 Gordon Ross :
> [...]
>>> If you setup idmap to use IDMU, then you'll get the UID/GID values
>>> provided by AD, which are presumably the same values your other LDAP
>>> clients will get from AD. :)
>>
>> 
>> -f
>>
>
> http://lmgtfy.com/?q=solaris+idmap+idmu

*sigh*
I was just giving a pointer to some doc I have spent considerable time
and effort to provide a consolidated ressource for anybody facing this
problem.
You may notice that using idmu is one the things explained in great length.
Feel free to add links and add enhancements.
-f

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


Re: [OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

2012-08-09 Thread Gordon Ross
On Thu, Aug 9, 2012 at 11:56 PM, Frank Lahm  wrote:
> 2012/8/10 Gordon Ross :
[...]
>> If you setup idmap to use IDMU, then you'll get the UID/GID values
>> provided by AD, which are presumably the same values your other LDAP
>> clients will get from AD. :)
>
> 
> -f
>

http://lmgtfy.com/?q=solaris+idmap+idmu

-- 
Gordon Ross 
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] ActiveDirectory UID mapping (netatalk)

2012-08-09 Thread Frank Lahm
2012/8/10 Gordon Ross :
> On Tue, Aug 7, 2012 at 9:25 AM, James Relph  wrote:
>>> I've got a server hooked up to a 2003 AD and CIFS and netatalk are both 
>>> allowing AD users to login (netatalk 3 via PAM).  One thing that's a bit 
>>> puzzling is that the afpd process correctly gets the correct username 
>>> mapping (and shows up as being owned by the correct user with a ps 
>>> listing), but whatever the user writes is only written as UID 60001 (ie. 
>>> nobody).
>>
>> Update time; after a further dig I assume that the reason the UID isn't 
>> being written to the filesystem is due to this (from the idmap man page):
>>
>> "To prevent aliasing problems, all file systems, archive and backup  
>> formats, and  protocols  must store SIDs or map all UIDs and GIDs in the 
>> 2^31 to 2^32 - 2 range  to  the  nobody user and group."
>>
>> So, the question becomes, is it possible to get OpenIndiana to store the 
>> SIDs for users, and if not, why will it store the GID as correctly mapped, 
>> but the UID is translated to 60001?  I can get around this with static maps, 
>> but obviously that's not ideal based on duplicating the AD user listing (can 
>> be scripted at least).
>>
>> What's even weirder is that the CIFS server happily stores the UID in the 
>> filesystem even if the ephemerally mapped UID is in the 2^31 to 2^32 range.
>>
>> Very, very odd.
>>
>> Any insight gratefully appreciated!
>>
>> James.
>
> If you setup idmap to use IDMU, then you'll get the UID/GID values
> provided by AD, which are presumably the same values your other LDAP
> clients will get from AD. :)


-f

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


Re: [OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

2012-08-09 Thread Gordon Ross
On Tue, Aug 7, 2012 at 9:25 AM, James Relph  wrote:
>> I've got a server hooked up to a 2003 AD and CIFS and netatalk are both 
>> allowing AD users to login (netatalk 3 via PAM).  One thing that's a bit 
>> puzzling is that the afpd process correctly gets the correct username 
>> mapping (and shows up as being owned by the correct user with a ps listing), 
>> but whatever the user writes is only written as UID 60001 (ie. nobody).
>
> Update time; after a further dig I assume that the reason the UID isn't being 
> written to the filesystem is due to this (from the idmap man page):
>
> "To prevent aliasing problems, all file systems, archive and backup  formats, 
> and  protocols  must store SIDs or map all UIDs and GIDs in the 2^31 to 2^32 
> - 2 range  to  the  nobody user and group."
>
> So, the question becomes, is it possible to get OpenIndiana to store the SIDs 
> for users, and if not, why will it store the GID as correctly mapped, but the 
> UID is translated to 60001?  I can get around this with static maps, but 
> obviously that's not ideal based on duplicating the AD user listing (can be 
> scripted at least).
>
> What's even weirder is that the CIFS server happily stores the UID in the 
> filesystem even if the ephemerally mapped UID is in the 2^31 to 2^32 range.
>
> Very, very odd.
>
> Any insight gratefully appreciated!
>
> James.

If you setup idmap to use IDMU, then you'll get the UID/GID values
provided by AD, which are presumably the same values your other LDAP
clients will get from AD. :)

-- 
Gordon Ross 
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] Code Bounty (Active Directory Integration)

2012-08-09 Thread Gordon Ross
On Wed, Aug 8, 2012 at 6:59 PM, James Relph  wrote:
> As may have become obvious from my last few posts we've been looking at 
> Active Directory integration for the past few weeks (and pretty hard for the 
> past week).  Obviously the CIFS server integration with AD seems pretty 
> reasonable straight out of the box, but other services that want to use AD 
> user details (et. netatalk in our case - NetAFP have been very helpful in 
> looking into this with us) seem to have pretty poor integration unless you go 
> towards LDAP integration with AD (that means either modifying the AD schema 
> or something like IDMU - which means touching the AD again).
>
> We have a pretty big interest in getting something working that doesn't 
> involve touching the AD too much, as that can immediately put off the Windows 
> admins we tend to deal with.  Ideally something with a similar featureset to 
> the Mac OS X AD plugin would be ideal (obviously that's a system we know 
> well!).  The OS X plugin doesn't require any changes to the AD schema for 
> general operation and can immediately be used by other services/applications 
> on the local system without any further work.
>
> If anyone is interested in looking into improving the AD integration in 
> OpenIndiana, if you drop me an email we can discuss a project bounty on this. 
>  We've got a potentially reasonably large budget for funding work on this as 
> we can see some business opportunities that this would make significantly 
> easier.
>
> Thanks,
>
> James.

My advice would be to make it easier to use IDMU.  The modifications
to AD to support IDMU are quite widely accepted these days, at least
in organizations that have both Windows and *nix.

The part that's a pain is setting up the LDAP client configuration.
In windows it's trivial. In illumos it requires knowing quite a lot
about LDAP configuration options.

-- 
Gordon Ross 
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] [oi-dev] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Jesus Cea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/08/12 22:55, Lou Picciano wrote:
> Really, the developer has fully granular control over which binary
> to use in a given environment; they coexist quite nicely in
> separate trees. (Some crazy developer might well have 2.4, 2.6, 2.7
> and 3.2, all in harmonious cohabitation.)

This is actually quite common. My Solaris 10 development machine:

"""
[root@babylon5 jcea]# d /usr/local/bin/python*
lrwxrwxrwx 1 root root   7 Apr 12 13:06 /usr/local/bin/python ->
python2
lrwxrwxrwx 1 root root   9 Apr 12 13:06 /usr/local/bin/python2 ->
python2.7
- -rwxr-xr-x 1 root root 3108840 Apr 24  2008 /usr/local/bin/python2.3
- -rwxr-xr-x 1 root root 3340612 Apr 24  2008 /usr/local/bin/python2.4
- -rwxr-xr-x 1 root root7796 Mar 14  2008 /usr/local/bin/python2.5
- -rwxr-xr-x 1 root root1424 Mar 14  2008
/usr/local/bin/python2.5-config
- -rwxr-xr-x 1 root root7848 Oct  4  2010 /usr/local/bin/python2.6
- -rwxr-xr-x 1 root root1424 Oct  4  2010
/usr/local/bin/python2.6-config
- -rwxr-xr-x 1 root root9184 Apr 12 13:05 /usr/local/bin/python2.7
- -rwxr-xr-x 1 root root1624 Apr 12 13:06
/usr/local/bin/python2.7-config
lrwxrwxrwx 1 root root  16 Apr 12 13:06
/usr/local/bin/python2-config -> python2.7-config
- -rwxr-xr-x 3 root root   19548 Apr 12 13:31 /usr/local/bin/python3
- -rwxr-xr-x 1 root root   10276 Apr 22  2009 /usr/local/bin/python3.0
- -rwxr-xr-x 1 root root1401 Apr 22  2009
/usr/local/bin/python3.0-config
- -rwxr-xr-x 1 root root   12444 Jun 13  2011 /usr/local/bin/python3.1
- -rwxr-xr-x 1 root root1401 Jun 13  2011
/usr/local/bin/python3.1-config
- -rwxr-xr-x 3 root root   19548 Apr 12 13:31 /usr/local/bin/python3.2
lrwxrwxrwx 1 root root  17 Apr 12 13:31
/usr/local/bin/python3.2-config -> python3.2m-config
- -rwxr-xr-x 3 root root   19548 Apr 12 13:31 /usr/local/bin/python3.2m
- -rwxr-xr-x 1 root root1826 Apr 12 13:31
/usr/local/bin/python3.2m-config
lrwxrwxrwx 1 root root  16 Apr 12 13:31
/usr/local/bin/python3-config -> python3.2-config
lrwxrwxrwx 1 root root  14 Apr 12 13:06
/usr/local/bin/python-config -> python2-config
"""

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBUCRueZlgi5GaxT1NAQJoaQP/WhhveR55Eya1SulSm0tX9abdLPvJLvKe
fbGBjDdUwIpi35lao3/rRjKJllQAMUI4U/gdM1Q7j1rKSHiidyUxtB5Goe5nOjK9
8AXgw6BkzTrKG4P4WKhvtcGB/0gjaG6tJdxeqrs9VWc2yBOt8eh2Wr1mE3KUZJz5
98+FGfyr7HY=
=gs3Y
-END PGP SIGNATURE-

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


Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Lou Picciano



From: "Jan Owoc"  
To: "Discussion list for OpenIndiana"  
Sent: Thursday, August 9, 2012 9:37:32 AM 
Subject: Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for 
OpenIndiana?? 
On Thu, Aug 9, 2012 at 7:03 AM, Milan Jurik  wrote: 
> Sooner or later Python 3.2 will be provided in OI SFE but I am not sure how 
> much it can coexists with 2.6 




Many GNU/Linux distributions have both a Python2 and a Python3 in 
their repositories. I happen to have both installed on one of my 
systems. 










We do quite a bit of 'experimentation' with various versions of Python, so have 
several versions installed at a given moment. The Python 'altinstall' option is 
your friend here through all v2s of python. In fact - if memory serves, since 
v3.0(?), I believe 'make install' is now an alias for 'make altinstall'. The 
'make fullinstall' option now exists for when you're ready to make the jump to 
v3-as-default. 


Really, the developer has fully granular control over which binary to use in a 
given environment; they coexist quite nicely in separate trees. (Some crazy 
developer might well have 2.4, 2.6, 2.7 and 3.2, all in harmonious 
cohabitation.) 


Of course, the only big gotcha is that the binary named 'python' is called, by 
default, by many things - and so should be agreed upon. We can make the 
determination of which version is to be so blessed as 'The OS Version' as 
necessary bits and pieces make it into versions. 


Fwiw, I've suggested we use these binary naming conventions within our own 
userland builds; they seem to accommodate most developer use cases (we have 
many), and allow for rapid transition in the future; for example, for all the 
system-level uses of python. 



(OK, I had to look it up: see release notes for 3.0a5: 
http://www.python.org/getit/releases/3.0.1/NEWS.txt ) 





The way it works is similar to how it's frequently done with gcc, 
where there is a series of symbolic links, with the plain "python" 
command pointing toward the version that is considered most universal: 


~$ ls -l /usr/bin/pyth* 
lrwxrwxrwx 1 root root 9 Apr 23 10:06 /usr/bin/python -> python2.7 
lrwxrwxrwx 1 root root 9 Apr 23 10:06 /usr/bin/python2 -> python2.7 
-rwxr-xr-x 1 root root 2989480 Jul 31 23:40 /usr/bin/python2.7 
-rwxr-xr-x 1 root root 1652 Jul 31 23:40 /usr/bin/python2.7-config 
lrwxrwxrwx 1 root root 16 Apr 17 11:20 /usr/bin/python2-config -> 
python2.7-config 
lrwxrwxrwx 1 root root 9 Apr 14 23:13 /usr/bin/python3 -> python3.2 
lrwxrwxrwx 1 root root 11 May 3 09:52 /usr/bin/python3.2 -> python3.2mu 
-rwxr-xr-x 1 root root 2954048 May 3 09:52 /usr/bin/python3.2mu 
lrwxrwxrwx 1 root root 11 Apr 14 23:13 /usr/bin/python3mu -> python3.2mu 
lrwxrwxrwx 1 root root 16 Apr 17 11:20 /usr/bin/python-config -> 
python2.7-config 


When I have a program that *requires* Python 3.2, it usually knows (or 
can be configured) to call "python3". 


Cheers, 
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] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Milan Jurik
Hi,

Jan Owoc píše v čt 09. 08. 2012 v 07:37 -0600:
> On Thu, Aug 9, 2012 at 7:03 AM, Milan Jurik  wrote:
> > Sooner or later Python 3.2 will be provided in OI SFE but I am not sure how
> > much it can coexists with 2.6
> 
> Many GNU/Linux distributions have both a Python2 and a Python3 in
> their repositories. I happen to have both installed on one of my
> systems.
> 
> The way it works is similar to how it's frequently done with gcc,
> where there is a series of symbolic links, with the plain "python"
> command pointing toward the version that is considered most universal:
> 
> ~$ ls -l /usr/bin/pyth*
> lrwxrwxrwx 1 root root   9 Apr 23 10:06 /usr/bin/python -> python2.7
> lrwxrwxrwx 1 root root   9 Apr 23 10:06 /usr/bin/python2 -> python2.7
> -rwxr-xr-x 1 root root 2989480 Jul 31 23:40 /usr/bin/python2.7
> -rwxr-xr-x 1 root root1652 Jul 31 23:40 /usr/bin/python2.7-config
> lrwxrwxrwx 1 root root  16 Apr 17 11:20 /usr/bin/python2-config ->
> python2.7-config
> lrwxrwxrwx 1 root root   9 Apr 14 23:13 /usr/bin/python3 -> python3.2
> lrwxrwxrwx 1 root root  11 May  3 09:52 /usr/bin/python3.2 -> python3.2mu
> -rwxr-xr-x 1 root root 2954048 May  3 09:52 /usr/bin/python3.2mu
> lrwxrwxrwx 1 root root  11 Apr 14 23:13 /usr/bin/python3mu -> python3.2mu
> lrwxrwxrwx 1 root root  16 Apr 17 11:20 /usr/bin/python-config ->
> python2.7-config
> 
> When I have a program that *requires* Python 3.2, it usually knows (or
> can be configured) to call "python3".
> 

well, for long time we had python 2.4 and 2.6 in OpenSolaris. So the
infrastructure is in place, only somebody has to prepare bits for
oi-build. In SFE there is spec for python3, only clash in deliverables
is 2to3 which is delivered by OI 2.6 already.

> Cheers,
> Jan

Best regards,

Milan


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


Re: [OpenIndiana-discuss] Synchronizing Sun DHCP servers

2012-08-09 Thread Dave Miner

On 08/09/12 07:59, James Carlson wrote:

Jim Klimov wrote:

   I wondered if the Sun DHCP server, also provided in OI, supports
synchronization of instances - i.e. two boxes providing addresses
for the same range, "should" support interchange of leased address
lists, defined macros (dhcptab) and so on.


Yes.  The simplest answer is to use the SUNWfiles backend (see
dhcp_modules(5)), and share the files via NFS between servers.  The more
complex (but much more scalable) way is via NIS+ (on Solaris 10, but not
OpenIndiana; NIS+ is dead).  Amusingly, the man page still talks about
"three" built-in mechanisms but then describes only two.


Good to see you're still better at noticing details than most anyone I 
know :-)




You can also write your own backend to do anything you want; see the
"Solaris DHCP Service Developer's Guide:"

http://docs.oracle.com/cd/E19253-01/806-6829/806-6829.pdf



That would be my suggestion, too.


   Perhaps a shared LDAP backend can be implemented?


I'm sure that could be done as well.  I don't recall if it was ever
done, but I would have expected that it would have been an ARC-required
portion of the NIS+ to LDAP transition strategy.  I'd expect that Dave
Miner at Oracle would know for sure if anyone does.



No, we never got around to building one; I seem to recall we'd started a 
prototype back in the late '90's but it never got to be a priority.


Dave

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


Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Francois Dion
On Thu, Aug 9, 2012 at 9:03 AM, Milan Jurik  wrote:
> On 09.08.2012 14:33, Francois Dion wrote:
>> Calibre is written in python, not just the build script. The list of
>> requirements is (the minimum versions):
>>
>> python  2.7.1 not 3.x
> Sooner or later Python 3.2 will be provided in OI SFE but I am not sure how
> much it can coexists with 2.6

As Jan points out in his post 2.x and 3.x can coexist fine. By design,
since python 3 is so different from python 2.4-2.7 it is supposed to
be invoked as python3. Per the release "Python 3.0, also known as
“Python 3000” or “Py3K”, is the first ever intentionally backwards
incompatible Python release".

This duality is normal, and so you have a 2.x and a 3.x series interpreter.

As far as handling multiple python from a 2.x series, that is also
possible. For example, Solaris 10 is stuck at 2.4, so /usr/bin/python
is python 2.4. I installed 2.6 and If you put python2.6 in your #!
statement, then it will call that. You can also install setuptools to
that 2.6 and if you call the easy_install from the python 2.6, all the
eggs are fetched and installed correctly in the 2.6, even though 2.4
is the main version.

Going back to calibre, 3.x wouldn't help. It is written using syntax
that is unique to 2.x, and is close 2.6, except the heavy use of
dictionary features that are only in 2.7, such as dictionary
comprehension. I think this is the first 2.x based project I've
encountered to use that (calibre is also not your typical python
project in that it has quite a dependency on binary libs).

In other words, it needs python 2.7. We probably need it anyway if we
are to grow our python community.



Francois

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


Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Jan Owoc
On Thu, Aug 9, 2012 at 7:03 AM, Milan Jurik  wrote:
> Sooner or later Python 3.2 will be provided in OI SFE but I am not sure how
> much it can coexists with 2.6

Many GNU/Linux distributions have both a Python2 and a Python3 in
their repositories. I happen to have both installed on one of my
systems.

The way it works is similar to how it's frequently done with gcc,
where there is a series of symbolic links, with the plain "python"
command pointing toward the version that is considered most universal:

~$ ls -l /usr/bin/pyth*
lrwxrwxrwx 1 root root   9 Apr 23 10:06 /usr/bin/python -> python2.7
lrwxrwxrwx 1 root root   9 Apr 23 10:06 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root 2989480 Jul 31 23:40 /usr/bin/python2.7
-rwxr-xr-x 1 root root1652 Jul 31 23:40 /usr/bin/python2.7-config
lrwxrwxrwx 1 root root  16 Apr 17 11:20 /usr/bin/python2-config ->
python2.7-config
lrwxrwxrwx 1 root root   9 Apr 14 23:13 /usr/bin/python3 -> python3.2
lrwxrwxrwx 1 root root  11 May  3 09:52 /usr/bin/python3.2 -> python3.2mu
-rwxr-xr-x 1 root root 2954048 May  3 09:52 /usr/bin/python3.2mu
lrwxrwxrwx 1 root root  11 Apr 14 23:13 /usr/bin/python3mu -> python3.2mu
lrwxrwxrwx 1 root root  16 Apr 17 11:20 /usr/bin/python-config ->
python2.7-config

When I have a program that *requires* Python 3.2, it usually knows (or
can be configured) to call "python3".

Cheers,
Jan

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


Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Milan Jurik

Hi,

On 09.08.2012 14:33, Francois Dion wrote:

On Thu, Aug 9, 2012 at 6:08 AM, Apostolos Syropoulos
 wrote:


Sadly I don't think it's been built on OI.  There are Linux, OS X 
and
windows version - I guess you could install Ubuntu inside KVM and 
try it

there?
It's an amazing program.



I have downloaded the source and it is actually a Python script that
relies on Qt4. So it is not difficult to build it... We can't expect
everything from others!

A.S.


Calibre is written in python, not just the build script. The list of
requirements is (the minimum versions):

python  2.7.1 not 3.x
Python Imaging Library  1.1.6
Qt  4.8.0
PyQt4.9.1
python-mechanize0.1.11
ImageMagick 6.5.9
xdg-utils   1.0.2
lxml2.2.1
python-dateutil 1.4.1
cssutils0.9.9
BeautifulSoup   3.0.5
dnspython   1.6.0
poppler 0.12.0
podofo  0.8.2
libwmf  0.2.8
chmlib  0.40
ICU 4.4


That's from the official list. That doesn't look too bad at first,
since as was pointed out we have QT in SFE. SFE also provides ICU,
poppler and chmlib. libwmf compiles easily and so do sip/pyqt. The
rest is mostly python eggs. The two issues I have left:

podofo chokes in the compile due to ** vs *const* on 
pdfvecobjects.cpp

OI has Python 2.6 and this requires 2.7

For podofo, i'm sure I'll figure out the switch, but until the second
is resolved, there is no point in spending more time on this. Python
2.7 itself needs some stuff, and mostly compiles, but it needs
berkeley db 1.8.5. That version needs to be patched, and needs a
Makefile for OI etc, etc. The make on Python 2.7 is also failing to
build _curses and _curses_panel.

Then, once all of that is done, you have to create packages, even for
the python eggs (you dont want to force the user to issue a bunch of
easy_install commands in order to be able to use the package).

The main thing still is python 2.7 support in OI, because that
requires doing a bunch of 2.7 modules (look in packagemanager all the
2.6 modules...). Mint 13, Mac OS/X etc do provide 2.7 as 2.x, but
solaris 11 provides 2.6, like OI.



Sooner or later Python 3.2 will be provided in OI SFE but I am not sure 
how much it can coexists with 2.6


The other problem is poppler because you need poppler with Qt support 
which is not delivered by OI.


All specs are welcomed for Calibre dependencies.


Maybe this discussion should move to oi-dev... (cc'ed)

Francois



Best regards,

Milan

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


Re: [OpenIndiana-discuss] Synchronizing Sun DHCP servers

2012-08-09 Thread Michael Stapleton
I have not looked at this in a long time, But multiple SUN DHCP servers
used to be able to use a common NFS share of their configuration files.
Yes the server can be configured to ping(Test) the addresses.


Mike

michael.staple...@techsologic.com


On Thu, 2012-08-09 at 03:51 +0400, Jim Klimov wrote:

> Hello all,
> 
>I wondered if the Sun DHCP server, also provided in OI, supports
> synchronization of instances - i.e. two boxes providing addresses
> for the same range, "should" support interchange of leased address
> lists, defined macros (dhcptab) and so on.
> 
>Perhaps a shared LDAP backend can be implemented?
> 
>From what I currently see, there is multi-instance support, but
> it seems based on shared FS (i.e. NFS) to store the DHCP tables...
> are there any other options currently available, or reasonably easy
> to implement?
> 
>Secondly, does Sun DHCP support active probing (arp/ping) whether
> the IP address it is going to lease is actually available and not
> used by some squatter (or a client of another DHCP server), and
> logging the result?
> 
> Thanks,
> //Jim Klimov
> 
> ___
> 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] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Francois Dion
On Thu, Aug 9, 2012 at 6:08 AM, Apostolos Syropoulos
 wrote:
>>
>> Sadly I don't think it's been built on OI.  There are Linux, OS X and
>> windows version - I guess you could install Ubuntu inside KVM and try it
>> there?
>> It's an amazing program.
>>
>
> I have downloaded the source and it is actually a Python script that
> relies on Qt4. So it is not difficult to build it... We can't expect
> everything from others!
>
> A.S.

Calibre is written in python, not just the build script. The list of
requirements is (the minimum versions):

python  2.7.1 not 3.x
Python Imaging Library  1.1.6
Qt  4.8.0
PyQt4.9.1
python-mechanize0.1.11
ImageMagick 6.5.9
xdg-utils   1.0.2
lxml2.2.1
python-dateutil 1.4.1
cssutils0.9.9
BeautifulSoup   3.0.5
dnspython   1.6.0
poppler 0.12.0
podofo  0.8.2
libwmf  0.2.8
chmlib  0.40
ICU 4.4


That's from the official list. That doesn't look too bad at first,
since as was pointed out we have QT in SFE. SFE also provides ICU,
poppler and chmlib. libwmf compiles easily and so do sip/pyqt. The
rest is mostly python eggs. The two issues I have left:

podofo chokes in the compile due to ** vs *const* on pdfvecobjects.cpp
OI has Python 2.6 and this requires 2.7

For podofo, i'm sure I'll figure out the switch, but until the second
is resolved, there is no point in spending more time on this. Python
2.7 itself needs some stuff, and mostly compiles, but it needs
berkeley db 1.8.5. That version needs to be patched, and needs a
Makefile for OI etc, etc. The make on Python 2.7 is also failing to
build _curses and _curses_panel.

Then, once all of that is done, you have to create packages, even for
the python eggs (you dont want to force the user to issue a bunch of
easy_install commands in order to be able to use the package).

The main thing still is python 2.7 support in OI, because that
requires doing a bunch of 2.7 modules (look in packagemanager all the
2.6 modules...). Mint 13, Mac OS/X etc do provide 2.7 as 2.x, but
solaris 11 provides 2.6, like OI.

Maybe this discussion should move to oi-dev... (cc'ed)

Francois

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


Re: [OpenIndiana-discuss] Synchronizing Sun DHCP servers

2012-08-09 Thread James Carlson
Jim Klimov wrote:
>   I wondered if the Sun DHCP server, also provided in OI, supports
> synchronization of instances - i.e. two boxes providing addresses
> for the same range, "should" support interchange of leased address
> lists, defined macros (dhcptab) and so on.

Yes.  The simplest answer is to use the SUNWfiles backend (see
dhcp_modules(5)), and share the files via NFS between servers.  The more
complex (but much more scalable) way is via NIS+ (on Solaris 10, but not
OpenIndiana; NIS+ is dead).  Amusingly, the man page still talks about
"three" built-in mechanisms but then describes only two.

You can also write your own backend to do anything you want; see the
"Solaris DHCP Service Developer's Guide:"

http://docs.oracle.com/cd/E19253-01/806-6829/806-6829.pdf

>   Perhaps a shared LDAP backend can be implemented?

I'm sure that could be done as well.  I don't recall if it was ever
done, but I would have expected that it would have been an ARC-required
portion of the NIS+ to LDAP transition strategy.  I'd expect that Dave
Miner at Oracle would know for sure if anyone does.

>   Secondly, does Sun DHCP support active probing (arp/ping) whether
> the IP address it is going to lease is actually available and not
> used by some squatter (or a client of another DHCP server), and
> logging the result?

Yes.  And doing so is part of the standard.  See dhcpsvc.conf(4) and the
ICMP_VERIFY parameter.

-- 
James Carlson 42.703N 71.076W 

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


Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

2012-08-09 Thread Apostolos Syropoulos
> 
> Sadly I don't think it's been built on OI.  There are Linux, OS X and
> windows version - I guess you could install Ubuntu inside KVM and try it
> there?
> It's an amazing program.
>

I have downloaded the source and it is actually a Python script that
relies on Qt4. So it is not difficult to build it... We can't expect
everything from others!

A.S.

 
--
Apostolos Syropoulos
Xanthi, Greece


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


Re: [OpenIndiana-discuss] Synchronizing Sun DHCP servers

2012-08-09 Thread Volker A. Brandt
Hello Jim!


>I wondered if the Sun DHCP server, also provided in OI, supports
> synchronization of instances - i.e. two boxes providing addresses
> for the same range, "should" support interchange of leased address
> lists, defined macros (dhcptab) and so on.
>
>  Perhaps a shared LDAP backend can be implemented?

I think that the Sun DHCP server is deprecated.  Oracle is moving
to ISC in Solaris 11.  So nobody is really willing to spend any effort
on the old Sun DHCP.

But don't let that stop you. :-)


Regards -- Volker
-- 

Volker A. Brandt   Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt

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


Re: [OpenIndiana-discuss] Running VirtualBox

2012-08-09 Thread Jim Klimov

2012-08-09 6:37, Edward Ned Harvey wrote:

From: Jim Klimov [mailto:j...@cos.ru]
Sent: Wednesday, August 08, 2012 9:23 PM

I use a VNC server bound to localhost,


I tried pkg search vnc, and I saw a whole mess of vnc clients, but no server 
(at least no obvious server.)  What vnc server are you using? Where did you get 
it?



For historical reasons, we brew my own build of aged TightVNC,
coupled with a lightweight TWM window manager. We customized
the xstartup scripts and the TWM menu to our needs of whatever
X11 may be needed on a headless server (i.e. running Sun ONE
or Oracle GUI installers, and it works for VBox as well).
The xstartup script can use other WMs like GNOME, but it's too
clunky for a compact console. The gnome-terminal works in TWM
acceptably well, though ;)

//Jim Klimov

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


Re: [OpenIndiana-discuss] Running VirtualBox

2012-08-09 Thread Jim Klimov

2012-08-09 5:57, James C. McPherson пишет:

For most of the time you can use RDP consoles to VMs instead, but
yes GUI can be useful. Alternately, there are some Web-GUIs to
VirtualBox which essentially recreate the X11 GUI equivalent in
HTML (for general administrative tasks without need for X11), and
often include an RDP client to conveniently connect to consoles.


If you're using bridged networking, then you can ssh in, or use
xdmcp (if you set it up). The vboxheadless service is handy to have
as well too. I've got it configured, but haven't needed to use it
in quite a while since my use-cases changed.


Well, "console" access in VirtualBox - be it via RDP or local X11 -
is more like a KVM (Keyboard-Video-Mouse) redirection in an IPMI
BIOS for a server. You can access virtual BIOS, bootloader, kmdb
and other stages of non-OS, where guest-OS-hosted SSH or VNC or
X11 servers won't be accessible (or even running yet).

The VirtualBox GUI console mode is superior to RDP one in providing
a menu with controls to shutdown/pause/savestate the VM, to turn
on and off some components (CD/DVD redirection, networks, etc.)
IIRC same can be done via CLI, but less conveniently, or wrapped
in the third-party HTML consoles with I did not test extensively.

Also the GUI console allows for window integration of guest's
programs into your window manages so they seem like native
graphical-interfaced programs.

//Jim


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