Re: [OmniOS-discuss] LX on OmniOS update
> On Aug 26, 2016, at 12:54 PM, Michael Rasmussen wrote: > > On Fri, 26 Aug 2016 11:51:41 -0400 > Dan McDonald wrote: > >> - The "zoneadm -z install" script now can take a "-t " >> argument in lieu of a "-s ZFS-send-stream" argument. Both gzipped and full >> will work. Thanks to Peter Tribble for providing some URLs with tarballs >> that work. And I quote: >> > /usr/lib/brand/lx/lx_install[72]: gtar: not found [No such file or directory] > > Seems you have forgotten a dependency? Thank you! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX on OmniOS update
On Fri, 26 Aug 2016 11:51:41 -0400 Dan McDonald wrote: > - The "zoneadm -z install" script now can take a "-t " argument > in lieu of a "-s ZFS-send-stream" argument. Both gzipped and full will work. > Thanks to Peter Tribble for providing some URLs with tarballs that work. > And I quote: > /usr/lib/brand/lx/lx_install[72]: gtar: not found [No such file or directory] Seems you have forgotten a dependency? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: It may be that your whole purpose in life is simply to serve as a warning to others. pgpayQ3bfb8tp.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LDAP external auth for CIFS service
I should also mention: The other solution for the problem of "centralized Windows accounts in a Unix shop" is to run a Samba AD server somewhere, and point your other clients that want LDAP to that. That way you can just tell the Windows clients to use domain accounts. On Fri, Aug 26, 2016 at 12:14 PM, Gordon Ross wrote: > Sorry for the delay -- been quite busy. I do look at this list, but > only occasionally. > > The way LDAP auth. works in SMB servers like Samba is that the server > allows SMB clients (i.e. Windows) to logon using accounts that work > the same as "local" accounts (what Windows would call "local" > accounts, meaning they are NOT domain accounts). However, while the > SMB clients think these are "local" accounts, the server uses > something akin to the name service switch functions for LDAP to get > the details of these accounts needed for SMB. > > Such accounts are not really "local", but are defined in your LDAP > service. The SMB server needs a way to get some Windows-specific > details about those accounts from LDAP, including the "NT password > hash" (for authentication) and some other Windows-ish details. > > The current LDAP libraries in illumos are sufficient for this (though > for other reasons, it would be nice if we could update them some day). > What's missing is some "glue" in the name service switch design, and > perhaps a new lookup method for the "NT password hash", which is > similar conceptually to the "shadow password" back-end functions. One > can probably pretty much copy/paste the LDAP back-end function for > shadow passwd. to make the "ntpass" or whatever we call this new > nsswitch method. The current /var/smb/smbpasswd stuff, currently > accessed directly from libsmb should really go through the "files" > back-end, and we might want to consider taking the opportunity to > change the format of that file (though that means doing some format > conversion work during upgrades). Once a new nsswitch method for > "ntpass" (or whatever) is in place, the parts of this in the SMB > server (mostly libsmb) are fairly easy. > > Requests for this feature have come up from time to time over the last > few years, but (so far) not from anyone who wanted it badly enough to > pay for the work. > > Gordon > > > On Thu, Aug 18, 2016 at 11:15 AM, Dan McDonald wrote: >> >>> On Aug 18, 2016, at 11:04 AM, Mick Burns wrote: >>> >>> *bump* >>> anyone ? >> >> I'm going to forward your note to someone I know who works on CIFS. He's >> not on this list. >> >> Stay tuned, >> Dan >> >> ___ >> OmniOS-discuss mailing list >> OmniOS-discuss@lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LDAP external auth for CIFS service
Sorry for the delay -- been quite busy. I do look at this list, but only occasionally. The way LDAP auth. works in SMB servers like Samba is that the server allows SMB clients (i.e. Windows) to logon using accounts that work the same as "local" accounts (what Windows would call "local" accounts, meaning they are NOT domain accounts). However, while the SMB clients think these are "local" accounts, the server uses something akin to the name service switch functions for LDAP to get the details of these accounts needed for SMB. Such accounts are not really "local", but are defined in your LDAP service. The SMB server needs a way to get some Windows-specific details about those accounts from LDAP, including the "NT password hash" (for authentication) and some other Windows-ish details. The current LDAP libraries in illumos are sufficient for this (though for other reasons, it would be nice if we could update them some day). What's missing is some "glue" in the name service switch design, and perhaps a new lookup method for the "NT password hash", which is similar conceptually to the "shadow password" back-end functions. One can probably pretty much copy/paste the LDAP back-end function for shadow passwd. to make the "ntpass" or whatever we call this new nsswitch method. The current /var/smb/smbpasswd stuff, currently accessed directly from libsmb should really go through the "files" back-end, and we might want to consider taking the opportunity to change the format of that file (though that means doing some format conversion work during upgrades). Once a new nsswitch method for "ntpass" (or whatever) is in place, the parts of this in the SMB server (mostly libsmb) are fairly easy. Requests for this feature have come up from time to time over the last few years, but (so far) not from anyone who wanted it badly enough to pay for the work. Gordon On Thu, Aug 18, 2016 at 11:15 AM, Dan McDonald wrote: > >> On Aug 18, 2016, at 11:04 AM, Mick Burns wrote: >> >> *bump* >> anyone ? > > I'm going to forward your note to someone I know who works on CIFS. He's not > on this list. > > Stay tuned, > Dan > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX on OmniOS update
I've updated all of the following URLs:
> On Jul 1, 2016, at 3:04 PM, Dan McDonald wrote:
> First some URLs. The git repos are:
>
> https://github.com/danmcd/io-lx-public/
>
> https://github.com/danmcd/ob-lx-public/
>
> The latter has only one small change in its manifests. The former is where
> the big work is. Feel free to clone/pull and toy around. At this time, I
> will consider PRs, but likely not issues unless they accompany a PR. If you
> have LX-for-OmniOS suggestions or issues, please bring them up on the
> omnios-discuss mailing list.
>
> I have webrevs of io-lx against illumos-omnios AND against illumos-joyent:
>
> http://kebe.com/~danmcd/webrevs/io-lx-public/
>
> http://kebe.com/~danmcd/webrevs/io-lx-public-vs-joyent/
>
> And finally, I have an IPS server with bloody + LX on it. You should
> retarget your "omnios" publisher on a bloody install to it if you want to try
> them out:
>
> http://pkg.omniti.com/omnios/LX/
You can update your normal OmniOS to bloody, and then switch publishers. If
you already have switched publishers, you can/should do a "pkg update" now,
modulo SunSSH removal (see below).
Biggest changes apart from merges with illumos-omnios (up to fe93252) and
illumos-joyent (up to 0c8abfc) include:
- The lx_boot scripts now do NOT clobber "resolv.conf" unless it's configured
in zonecfg(1M) Joyent-style.
- The "zoneadm -z install" script now can take a "-t " argument
in lieu of a "-s ZFS-send-stream" argument. Both gzipped and full will work.
Thanks to Peter Tribble for providing some URLs with tarballs that work. And I
quote:
> Some projects make filesystem tarballs available. For example Ubuntu
> have their cloud images:
>
> https://cloud-images.ubuntu.com/
>
> Looking around for the root tarballs should give you something useful.
> (The cloud images are what are used to create the Ubuntu Docker images,
> so you get the unmodified version which might actually be more useful.)
>
> Or some images here might be useful.
>
> http://download.proxmox.com/images/system/
>
> I've used the alpine image from there successfully.
The proxmox one provided me with a good Debian one. (SLIGHTLY off-rev from a
joyent one, but the 3.4.0 kernel setting matched and made it work.)
- SunSSH is gone, which means you have to follow the advice I gave on this
week's bloody update: either eliminate SunSSH prior to upgrade OR include the
--reject flags for your "pkg update". NOTE: I'm seeing some potential
problems with ipkg/lipkg zones with stock bloody not getting their SunSSH
eliminated with --reject, that will translate here as well.
- If I haven't mentioned it already, you MUST set the kernel version:
# zonecfg -z lx0
zonecfg:lx0> add attr
zonecfg:lx0> set name=kernel-version
zonecfg:lx0> set type=string
zonecfg:lx0> set type=4.3.0(NOTE: That level is good for Ubuntu 16 and
CentOS 7)
zonecfg:lx0> end
zonecfg:lx0> exit
#
The joyent image metadata is a good guide for what to set it for which distro.
UPCOMING: We have a couple of things in the works right now:
* IP address configuration persistence. The Joyent folks configure zones'
networking via zonecfg(1M) properties. Not every OmniOS admin is used to that,
so we're going to persist /native/sbin/{ipadm,route} persistence.
* IP address configuration via zonecfg(1M). Since the code is mostly there,
and at least some internal OmniTI customers are very excited about the
possibility of doing LX zones this way. We will also be working on this.
Thanks!
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
