Re: [OmniOS-discuss] how to set a ipv6 address in a lxzone
On Thu, Mar 09 2017 10:07:22 +0100, Manuel Oetiker wrote: > I what to setup a lxzone with a ipv4 and a ipv6 address. > > /usr/sbin/zonecfg -z franz add net; add property > (name=ips,value="44.141.183.210/24") ; add property > (name=gateway,value="44.141.183.193") ; add property > (name=primary,value="true") ; set physical=franz0; end > > this ist working but how can I add the ipv6 address? I found the following works for SLAAC+DHCP, but I haven't tested static addresses: add net set physical=foo0 add property (name=primary,value="true") add property (name=ips,value="dhcp,addrconf") end ie. just add another address into the same property and delimit them with commas. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] An alternative to HP Microserver Gen8?
On Thu, Dec 01 2016 08:35:16 +, C. L. Martinez wrote: > I need a new NAS for my home :)) .. Due to old hardware supplied on HP > Microserver Gen8 (and it doesn't seems that HP release another model soon), I > would like to know if exists some alternative with similar features: low > noise, compact, etc. I use this with a small mini-ITX case that fits six 3.5" disks: https://www.supermicro.com/products/motherboard/Atom/X10/A1SAi-2550F.cfm -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OpenSSH and reverse DNS
On Tue, Nov 29 2016 13:30:17 +0200, Lauri Tirkkonen wrote: > On Tue, Nov 29 2016 10:47:10 +0100, Olaf Marzocchi wrote: > > Dear all, > > Since I upgraded to OpenSSH I have the following problem with DNS: > > reverse mapping checking getaddrinfo for hostxxx.retail.telecomitalia.it > > [_ip_] failed - POSSIBLE BREAK-IN ATTEMPT! Another interesting thing to note is that this particular log message was changed in 7.3: https://github.com/openssh/openssh-portable/commit/e690fe85750e93fca1fb7c7c8587d4130a4f7aba So it actually may be the *client* that is calling get_canonical_hostname (which is strange, because only sshd should be doing that). And so it is: https://github.com/omniti-labs/omnios-build/blob/master/build/openssh/patches/0015-GSS-API-key-exchange-support.patch#L1652 The culprit is thus the GSSAPI patch (which I personally don't even agree with, but oh well). I think the option you need to disable in the client's ssh_config is GSSAPIKeyExchange. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OpenSSH and reverse DNS
On Tue, Nov 29 2016 10:47:10 +0100, Olaf Marzocchi wrote: > Dear all, > Since I upgraded to OpenSSH I have the following problem with DNS: > reverse mapping checking getaddrinfo for hostxxx.retail.telecomitalia.it > [_ip_] failed - POSSIBLE BREAK-IN ATTEMPT! > The remote SSH server has always been OenSSH, the issue appeared when the > client (OmniOS) got updated. Strange - why would the server suddenly start caring about DNS checks if the client was updated? > I have no access to the DNS records. I already have a dynamic DNS configured, > but the reverse one is out of my reach. > > I found online possible solutions and I described the issue also here without > success: > http://superuser.com/questions/1149850/how-to-disable-the-message-reverse-mapping-checking-getaddrinfo-for-xxx-failed > > "UseDNS no" helped me to be able at least to connect, but still I cannot > disable the warning. Since I launch daily rsync backups via cron, I get > emails every morning without any real security issue (in my case). "UseDNS no" sshd option should indeed resolve this -- my reading of both the manual and code is that it prevents sshd from resolving client addresses. If you have console access to the server try 'sshd -T | grep usedns' to see if it actually is using the correct configuration file. I guess that the sshd you're using could also be doing something weird, but in stock 7.3p1 remote_hostname is only called from auth_get_canonical_hostname, which always seems to get options.use_dns from the caller. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Mirroring bloody package repository fails
On Thu, Aug 11 2016 13:11:56 -0400, Dan McDonald wrote: > > > On Aug 11, 2016, at 3:13 AM, Lauri Tirkkonen <loth...@iki.fi> wrote: > > > > Hi, starting between 17.00 and 21.00 UTC yesterday (Wed Aug 10), there > > seems to be something funky with the omnios bloody package repository, > > and mirroring it fails: > > I think a package bound for 014 got pushed to the wrong internal server. I > think we're better now: Thanks, but it still seems to be failing (on a different package): + pkgrecv -s http://pkg.omniti.com/omnios/bloody -d /niksula/pkg-omnios/bloody --clone -p omnios Processing packages for publisher omnios ... Retrieving and evaluating 2 package(s)... pkgrecv: Invalid content: manifest hash failure: fmri: pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151018:20160810T175732Z expected: 3626fd45ab899d47b3a5feb79caa3066afe978ff computed: e51469d1ea3460e2a1e3530300ebf4acac9c55a7. (happened 4 times) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Mirroring bloody package repository fails
Hi, starting between 17.00 and 21.00 UTC yesterday (Wed Aug 10), there seems to be something funky with the omnios bloody package repository, and mirroring it fails: pkgr...@pkg.niksula.hut.fi:~$ pkgrecv -s http://pkg.omniti.com/omnios/bloody -d /niksula/pkg-omnios/bloody --clone -p omniosProcessing packages for publisher omnios ... Retrieving and evaluating 4 package(s)... pkgrecv: Invalid content: manifest hash failure: fmri: pkg://omnios/web/wget@1.18,5.11-0.151014:20160810T175414Z expected: eef89fd22bc8577c36f5815a30cc933f2e949d32 computed: c7bf74b2a812ec775585e6b864facb52bc47f6fe. (happened 4 times) This is interesting in that a 0.151014 branch version probably should not be in 'bloody'. Sure enough my mirror does not have one like that: pkgr...@pkg.niksula.hut.fi:~$ pkgrepo -s /niksula/pkg-omnios/bloody list wget PUBLISHER NAME O VERSION omniosweb/wget 1.18-0.151019:20160719T012111Z omniosweb/wget 1.18-0.151019:20160712T202302Z omniosweb/wget 1.17.1-0.151019:20160615T221114Z omniosweb/wget 1.17.1-0.151019:20160606T150112Z omniosweb/wget 1.17.1-0.151019:20160422T013322Z -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OpenSSL futures
On Mon, Apr 04 2016 22:15:12 +0100, Peter Tribble wrote: > On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald <dan...@omniti.com> wrote: > > I'm starting this thread to hear what the community has to say about where > > OmniOS should go w.r.t. its OpenSSL release. I have internal customers > > too, of course, but I'll engage them separately. We need to have an > > OpenSSL because illumos requires one. We *could* do the SmartOS thing and > > keep our own SUNW/OMNI*...() api set, though. > > > > They have to play those games because they ship 2 different openssl > instances, > though. (One with the platform, one via pkgsrc or whatever.) If you hide > the internal > copy, you still have to manage (or someone does, at any rate) compatibility > and > releases of the public copy. The problem doesn't go away, you just sweep it > under > someone else's carpet. Here's another viewpoint though: I would like to choose the SSL implementation used in my application stack, so I want this problem under my carpet. Not just because I believe it has security benefits (eg. getting ssl2 *actually* disabled; it couldn't be disabled in the OmniOS shipped OpenSSL because that broke binary compatibility), but also because my SSL library of choice ships a sane API (libtls [0]). If OmniOS keeps shipping OpenSSL as a mandatory component *without* changing its symbol names, I can't do what I want in my application stack. > Users will have binaries linked against the existing openssl libraries, and > those > need to continue to run. OmniOS has removed (ie. stopped shipping) some other libraries in the past [1], but I understand the OpenSSL story might be a little different. Perhaps there's a middle ground here though: it seems like you and I would both be happy if OmniOS kept shipping OpenSSL, but made it optional (although then obviously it would have to have another copy with mangled symbol names for the things illumos needs it for). [0]: http://man.openbsd.org/OpenBSD-current/man3/tls_accept_fds.3 [1]: eg. 151006 removed several libraries, including libgnutls and libgcrypt. http://omnios.omniti.com/wiki.php/ReleaseNotes/r151006 -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sshd logging
On Thu, Mar 31 2016 08:11:15 -0500, Schweiss, Chip wrote: > In sshd_config I have: > > # Syslog facility and level > SyslogFacility AUTH > LogLevel VERBOSE You tell it to log to the auth facility, but you also need to tell syslog to put auth messages where you want them. > *.err;kern.notice;auth.notice /dev/sysmsg You ask that auth messages higher than 'notice' level go to the console. A quick glance at my logs reveals most messages logged by sshd are at the 'info' level (which is lower than notice). > auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost) According to syslog.conf(4), this means that if the current machine has the same address as 'loghost' (which I think is an alias for localhost in the default /etc/hosts), then put auth.notice and above to /var/log/authlog, otherwise send them to the 'loghost' machine. But again, your log level is 'notice'; try bumping it to 'info' (and make sure that /var/log/authlog exists if that's where you want these logs). -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Volunteers for OpenSSH 7.2p2 testing?
On Tue, Mar 15 2016 10:47:05 -0400, Dan McDonald wrote: > > > On Mar 15, 2016, at 10:42 AM, Dan McDonald <dan...@omniti.com> wrote: > > > > Will fix and republish v. soon. > > Try "pkg update openssh openssh-server" now, and you should see DSA support > gone again (i.e. PR #82). Yep, it works, thanks. You mentioned on the PR that you'd backport it to supported releases as well; is that happening? https://github.com/omniti-labs/omnios-build/pull/82#issuecomment-192332860 -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Volunteers for OpenSSH 7.2p2 testing?
On Mon, Mar 14 2016 22:21:20 -0400, Dan McDonald wrote: > I have OpenSSH 7.2p2 compiled, thanks again to Joyent's Alex Wilson and his > set of patches (only one of which I remove, because we have our own > historical sshd_config patch). > > I'd like a few people with bloody to test it out, please. It will be on the > bloody repo server in about 30 minutes from now (11pm US/Eastern) so you can > "pkg update" to get it. Works fine here. omnios-build PR #82 doesn't seem to be applied to this build though? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
On Fri, Mar 04 2016 10:55:15 -0500, Dan McDonald wrote: > > > On Mar 4, 2016, at 10:43 AM, Lauri Tirkkonen <loth...@iki.fi> wrote: > > > > I fixed snapshot pruning for the source dataset and it's working again, > > but this still seems like a bug - I'll try to get steps to repro and > > report to illumos later. > > Damn... two steps ahead of me! > > Make sure you let the open-zfs list know alongside illumos. This is a bug > for z...@lists.illumos.org and develo...@open-zfs.org. Is an illumos-gate bug report not enough? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
On Fri, Mar 04 2016 14:17:48 +0200, Lauri Tirkkonen wrote:
> On Thu, Oct 08 2015 10:59:20 +0300, Lauri Tirkkonen wrote:
> > Assertion failed: ilen <= SPA_MAXBLOCKSIZE, file
> > ../common/libzfs_sendrecv.c, line 1706, function recv_read
>
> I have a repro of this now: a 17MB incremental replication stream, which
> coredumps 'zfs recv' (even when used with -n), on OmniOS r151014 and
> bloody alike. The filesystem in question is large, contains sensitive
> data, and has 162 child filesystems. The snapshots between which the
> incremental stream was generated were taken recursively.
I managed to tracked this down, and the root cause is a very large
amount of snapshots (169k) on the dataset from which the replication
stream was generated. Looking at zstreamdump, it seems like references
to all existing snapshots for the source dataset and its children are in
there (even though I generated the incremental stream between two
snapshots taken right after one another), and that caused a
dmu_replay_record_t in the stream to be larger than what recv expected:
> 80478e8::print dmu_replay_record_t
{
drr_type = 0 (DRR_BEGIN)
drr_payloadlen = 0x1140fbc
(SPA_MAXBLOCKSIZE is 1<<24, which is less than that)
I fixed snapshot pruning for the source dataset and it's working again,
but this still seems like a bug - I'll try to get steps to repro and
report to illumos later.
--
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
On Thu, Oct 08 2015 10:59:20 +0300, Lauri Tirkkonen wrote: > Assertion failed: ilen <= SPA_MAXBLOCKSIZE, file > ../common/libzfs_sendrecv.c, line 1706, function recv_read I have a repro of this now: a 17MB incremental replication stream, which coredumps 'zfs recv' (even when used with -n), on OmniOS r151014 and bloody alike. The filesystem in question is large, contains sensitive data, and has 162 child filesystems. The snapshots between which the incremental stream was generated were taken recursively. mdb has this to say: > $c libc.so.1`_lwp_kill+7(1, 6, 80467b8, fee91cdd, fef63000, 8046810) libc.so.1`raise+0x22(6, 0, 80467f8, fee6edb9) libc.so.1`abort+0xf3(8046810, 8046810, 6c, fed732cc, 65737341, 6f697472) libc.so.1`_assert(fedabf16, fedabefa, 7a3, feda93ad) libzfs.so.1`recv_read+0x3d(80a4548, 0, 80a7008, 1140fbc, 0, 8047390) libzfs.so.1`recv_read_nvlist+0x4a(80a4548, 0, 1140fbc, 804722c, 0, 8047390) libzfs.so.1`zfs_receive_package+0x100(80a4548, 0, 8047d9c, 8047bec, 80478e8, 8047390) libzfs.so.1`zfs_receive_impl+0x527(80a4548, 8047d9c, 0, 8047bec, 0, 0) libzfs.so.1`zfs_receive+0xc3(80a4548, 8047d9c, 80a1f88, 8047bec, 0, 0) zfs_do_receive+0x3dd(3, 8047cb0, 80768a0, 801, 0, 3) main+0x22c(fee10180, fef6d6a8, 8047ca0, 80557f7, 4, 8047cac) _start+0x83(4, 8047d90, 8047d94, 8047d99, 8047d9c, 0) and zstreamdump reports: SUMMARY: Total DRR_BEGIN records = 164 Total DRR_END records = 165 Total DRR_OBJECT records = 0 Total DRR_FREEOBJECTS records = 0 Total DRR_WRITE records = 0 Total DRR_WRITE_BYREF records = 0 Total DRR_WRITE_EMBEDDED records = 0 Total DRR_FREE records = 0 Total DRR_SPILL records = 0 Total records = 329 Total write size = 0 (0x0) Total stream length = 18194612 (0x115a0b4) Because there is sensitive data involved, I'm reluctant to share either the core or the stream, but would appreciate any cluebats. Thanks. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Extending the installer
On Fri, Feb 26 2016 23:53:13 +0100, PÁSZTOR György wrote: > If a network configuration / install improvement should be done, then I > vote for some auto-configuration-like thing. > It was a long time ago, when I installed omnios, but what I can imagine as > a useful developement on this field: > * If some pxe-based installer is provided > * If it can be customized with some pre-written installer answers, like > like debian's dai & debconf system, etc. Or if we could give a > sysconfig-like file url as a kernel param, and the installer would gather > that, and then it would done these presetups. That would be something > useful. A "setup tool" with gui... Why on earth?! kayak already can be and is used for network configuration in PXE installs, often with a 'Postboot' line. http://omnios.omniti.com/wiki.php/KayakClientOptions I believe this thread is about improving the interactive installer. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails
On Fri, Feb 26 2016 18:08:45 +0200, Lauri Tirkkonen wrote: > On Fri, Feb 26 2016 10:58:54 -0500, Dan McDonald wrote: > > And IIRC, the other person who reported this reported it on r151014. I > > think I need to backport this to '014 and '016. > > Yeah, I'm trying on 151014 as well. > > > Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? > > I'll bet a beer you can't. > > I'm running it on my bloody box now, will let you know. You're right, it works on bloody. I owe you a beer :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails
On Fri, Feb 26 2016 10:58:54 -0500, Dan McDonald wrote: > And IIRC, the other person who reported this reported it on r151014. I think > I need to backport this to '014 and '016. Yeah, I'm trying on 151014 as well. > Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? > I'll bet a beer you can't. I'm running it on my bloody box now, will let you know. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] pkgrecv --clone of omnios package repositories fails
Hi, I'm (finally) attempting to set up a local mirror for the omnios package repository, but getting this when attempting to pkgrecv --clone the r151016 repository, and a similar error for r151014, but bloody seemed to work fine: pkgrecv@pkg:/niksula/pkg-omnios$ pkgrecv -s http://pkg.omniti.com/omnios/r151016 -d /niksula/pkg-omnios/r151016 --clone -p omnios Processing packages for publisher omnios ... Retrieving and evaluating 1930 package(s)... DOWNLOADPKGS FILESXFER (MB) SPEED locale/lt-extra1930/1930 98719/987191510/1510 393k/s Verifying repository contents. Initiating repository verification. pkg://omnios/driver/audio/audiop16x 1/1931 -Traceback (most recent call last): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2391, in verify trust_anchors, sig_required_names, use_crls): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2288, in __gen_verify hashes, errors = self.__get_hashes(path, pfmri) File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2005, in __get_hashes fnames = fname.split() AttributeError: 'NoneType' object has no attribute 'split' Traceback (most recent call last): File "/usr/bin/pkgrepo", line 1689, in handle_errors __ret = func(*args, **kwargs) File "/usr/bin/pkgrepo", line 1665, in main_func return func(conf, pargs) File "/usr/bin/pkgrepo", line 1512, in subcmd_verify for verify_tuple in repo.verify(pub=xpub, progtrack=progtrack): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2396, in verify raise apx._convert_error(e) AttributeError: 'NoneType' object has no attribute 'split' pkgrepo: This is an internal error in pkg(5) version 1427212657. Please log a Service Request about this issue including the information above and this message. pkgrecv: Pkgrepo verify found errors in the updated repository. The original package catalog has been restored. The clone operation can be retried; package content that has already been retrieved will not be downloaded again. Contrary to what the message at the end claims, running it again will proceed to redownload everything and takes forever, so this is a bit annoying to debug from my end. Has anyone else seen this? Given that it works for the bloody repository, maybe it's a problem in a package in the r151014/r151016 repositories? Or should I not be using --clone? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Question on puppet agent for OmniOS
On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote: > Thanks for responding. I am new to puppet, and curious, why do you run > it from cron, instead of in daemon mode? Is it more secure, or is there > something else I am missing? It used to be that the agent was leaking memory in version 2.something when we first started using it. 'puppet kick' also existed then, to trigger an agent run from the master, but it doesn't anymore; we don't think there's any reason to run the agent as a daemon. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Question on puppet agent for OmniOS
On Wed, Feb 17 2016 15:24:14 -0600, Paul Jochum wrote: > For those that run puppet as an agent on OmniOS, which version do you > recommend using? I see that OpenCSW has a version, and Niksula also has one > (and are there any others available?). Is one version better than others? > I have tried installing the Niksula version, but I can't find any svcadm > scripts to start it up (or am I missing them?). We don't ship any, because we run our agents from cron with --onetime. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
On Thu, Nov 05 2015 17:47:56 -0500, Dale Ghent wrote: > 2) Several other in-tree components either depend on, or at least would > sorely miss a functional LDA (at a minimum). These include crond, FMA, > vi/vim, audit_warn(1M), rdist, mailx, and UUCP (ha!) "/usr/sbin/sendmail" is > also the value defined by _PATH_SENDMAIL in but nothing in-tree > seems to use it. Let's not forget nightly.sh's end-of-run mails and whatever > else in omnios-userland that expects a working mail transport to be present. I already said as much on github, but these are why I think OmniOS does need an MSA+LDA at least. > OPTION 2: > > 1) Kick in-tree sendmail to the curb, and let distros/distro users figure > MTAs out for themselves > 2) Improve mailwrapper(1M) to be cognizant of /usr/bin/mail, /usr/ucb/Mail, > /usr/bin/mailx and maybe provide some sort of no-frills local delivery only > to /var/mail functionality. > 3) Or no mail delivery functionality of any kind? What happens to the consumers listed above if this happens? > OPTION 3: > > 1) Replace in-tree sendmail with an alternative (unscientific survey shows > people seem to prefer Postfix) I've been trying to avoid painting this particular bikeshed until it's at least planned to be built, so I wouldn't draw any conclusions yet. > 2) Let users worry about any conversion process for sendmail -> postfix There's no I can see reason anyone wanting to keep using sendmail couldn't use a different copy, so I don't consider this a problem. > 3) Package it similarly to (OPTION 1a) so that it can be removed/replaced > easily from a packaging perspective > 4) We'll still need sendmail.org Sendmail source bits in order to deliver > libmilter and milter functionality into Postfix. Where does the milter requirement come from? Per KYSTY I would think OmniOS should only deliver what it needs to function itself. Are there milter consumers in -gate or omnios-userland? If you're asking for opinions on what to do, I don't think keeping sendmail on life support is worth it, which removes option 1. Since there are MSA/LDA consumers, option 2 isn't feasible either. That leaves only option 3, unless "do nothing" is an option. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
On Fri, Nov 06 2015 01:55:54 -0500, Dale Ghent wrote: > >> OPTION 2: > >> > >> 1) Kick in-tree sendmail to the curb, and let distros/distro users figure > >> MTAs out for themselves > >> 2) Improve mailwrapper(1M) to be cognizant of /usr/bin/mail, > >> /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills > >> local delivery only to /var/mail functionality. > >> 3) Or no mail delivery functionality of any kind? > > > > What happens to the consumers listed above if this happens? > > Thats where mailwrapper (or some component in addition to it) comes in and > provides a very basic local delivery only. Like, not even remote delivery, > and the destination user must be in /etc/passwd. No-frills, but it gets a > mail to some destination. It would need to be coded. Hell, it could be > written in perl or python for all I care. I have no final form in my head, > just a general concept. Ah, okay. I'm fine with that but it sounds like more work than dropping in an alternative. > >> 4) We'll still need sendmail.org Sendmail source bits in order to deliver > >> libmilter and milter functionality into Postfix. > > > > Where does the milter requirement come from? Per KYSTY I would think > > OmniOS should only deliver what it needs to function itself. Are there > > milter consumers in -gate or omnios-userland? > > Well, if we bring in a sendmail replacement and we neuter its features, no > one will use it or at least consider serious level of use of it; and it will > end up being uninstalled and thrown out like the sendmail we currently have. > This is a flaw that the current in-tree sendmail suffers from (in addition to > being woefully out of date) I'm not really saying we should actively neuter a replacement's features because OmniOS itself doesn't need them, but I don't see the point of bringing in milter either. > Which brings us back to the philosophical question - why include software > that nobody wants because its most basic level of functionality is often > insufficient? But if we don't include it, other things suffer or are degraded > in out-of-the-box functionality. I believe in KYSTY - but to a point. In > these grey areas of overlap, some exceptions or special considerations must > be made. Let's be real here. There are many area in illumos that someone can > point to and ask why its there if one to strictly interpret KYSTY in all > cases. Sure, generally speaking. In this particular context I believe users should ship their own if they want to deploy a mail server, but all nodes should be able to deliver mail locally. It would also be great if the default install lended itself to mail submission (eg. a satellite mailer configuration), perhaps even with opportunistic TLS, to cover more of the common use cases, but that might be just my personal bias talking. > > If you're asking for opinions on what to do, I don't think keeping > > sendmail on life support is worth it, which removes option 1. Since > > there are MSA/LDA consumers, option 2 isn't feasible either. That leaves > > only option 3, unless "do nothing" is an option. > > Well "do nothing" has been the apparent course of action for almost 6 years > now. But that's speaking in general illumos-gate terms. As far as OmniOS > goes, we can completely ignore that part of the tree and install our own > thing in our own way... but I want to at least explore the options which have > a bearing on illumos-gate (ie; the greater illumos community) first. True. I do think that excising sendmail and replacing it with something would also benefit the greater illumos community, but I'm already dreading a potential developer list discussion on the subject :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
On Thu, Nov 05 2015 13:18:26 +, Andy Fiddaman wrote: > On Wed, 4 Nov 2015, Dan McDonald wrote: > > ; > ; > On Nov 4, 2015, at 5:44 PM, Andy Fiddaman <omn...@citrus-it.net> wrote: > ; > > ; > > ; > Would a 'group' dependency give the desired result of the package being > ; > installed by default but still avoidable to those of us who don't want > ; > it? > ; > ; That's actually an interesting idea. I was thinking of "optional" as one > possibility, but I'm noticing that type=group and type=optional appear, in > practice, to be the same. Apparently when you uninstall a group package, > it's added to the image's avoid list. For you anti-sendmail types, that may > be a feature. :) > > sendmail is already an optional dependency of mailwrapper which is itself > required by SUNWcs. So if fresh installs aren't getting sendmail then > optional is not doing what you want here :( > I'm not sure if group would be any better. It is, I tested that a new empty image gets sendmail when I install entire into it. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
On Wed, Nov 04 2015 07:56:15 -0500, Dan McDonald wrote: > Does the *presence* of sendmail in a default install actually prevent > folks from using their preferred MTAs with the mediator (which still > works from what I can tell)? No. OmniOS being an IPS distro there are two ways to switch to a different MTA: the mediator (if the other MTA is an IPS package which also participates in the mediator) and mailwrapper configuration (otherwise). -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151016: perl build broken?
On Wed, Nov 04 2015 13:05:39 +0100, Dominik Hassler wrote:
> after upgrading to r16 I found that znapzend (pure perl program) got stuck in
> maintenance mode. The service status log file revealed the following:
> "EINPROGRESS" is not exported by the Errno module
>
> Checking the Errno.pm (core perl module) I found that the %err hash as well
> as the %EXPORT_TAGS hash are empty:
> BEGIN {
> %err = (
> );
> ...
> }
>
> ...
>
> our %EXPORT_TAGS = (
> POSIX => [qw(
> )]
> );
>
> The Errno.pm build depends on the errno.h header file
> (/usr/include/errno.h) which I found to be present on some of my
> OmniOS r16 boxes but not on all of them.
This issue is gcc5 related (there was one just like it in zsh,
actually). Upstream perl fix:
https://github.com/Perl/perl5/commit/816b056ffb99ae54642320e20dc30a59fd1effef
> As a temporary fix I copied the hashes from another Errno.pm on a non r16
> system.
>
> znapzend users be warned that upgrading to OmniOS r16 will currently stop
> znapzend from working.
Only if using the system perl for znapzend, my znapzend from
pkg.niksula.hut.fi works fine on 151016 ;)
--
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
On Tue, Nov 03 2015 18:39:18 -0800, Paul B. Henson wrote: > On Tue, Nov 03, 2015 at 07:33:40PM -0500, Dan McDonald wrote: > > > We may need to weaken "require" to something else. I know the bug > > filer is on this list. I'd appreciate a dialogue here on this > > subject. > > We don't use sendmail. I remember piping up when sendmail became a > requirement of 014 during its bloody phase, so I will restate -- please > don't make sendmail a hard dependency :(. What's the point of an > interposer allowing the use of whatever mail system you want if you're > forced to install one you don't want 8-/. Generally on operating systems > that allow multiple options of a specific service you add on the ones > you want after the base install. I'd say the box in the bug report > simply hadn't been fully configured yet. I reported the issue because I think it's very important that OmniOS ships with a working MTA out of the box, because things like cron do need one. AIUI, the point of mailwrapper and the added IPS mediations is that you can choose to install another one (that is not necessarily shipped by the OS vendor, or even shipped as an IPS package) and use it by default without the package manager fighting you. You don't have to *use* sendmail. I don't really understand why you're objecting to its mere presence on disk; it's not very large. > Honestly, I can't understand why anyone would *choose* to use sendmail > nowadays ;), if you want to install an MTA in the base how about you > package up postfix :)... We're currently running it from pkgsrc. OmniOS at present only ships one MTA choice, and that happens to be sendmail. I would not mind that being some other MTA, but I think there needs to be one in the base install. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody Terminfo problems
On Mon, Nov 02 2015 11:48:41 +0100, Jim Klimov wrote: > TL;DR: The OmniOS terminfo package seems broken after Oct 22 and > delivers too few files. Packaged software does not fall back to other > available locations. Packaged by who? > Same for vt100, vt220, ansi... > > I have terminfo packages installed and up-to-date, and while looking at the > system I see 3 locations at least: > > # find /opt -name terminfo -ls >11242 drwxr-xr-x 14 root root 14 Oct 29 14:45 > /opt/local/share/lib/terminfo Not shipped by OmniOS. Maybe this is from pkgsrc? > The /usr ones seem similar to OI/Hipster - they contain seemingly > equivalent content except most of the files are different at binary > level. Apparently, they come from terminfo and ncurses, and maybe > should be merged(?) in illumos-gate(?): > > # pkg search xterm > INDEX ACTION VALUE PACKAGE > basename file usr/gnu/share/terminfo/x/xterm > pkg:/library/ncurses@5.9-0.151015 > basename file usr/share/lib/terminfo/x/xterm > pkg:/system/data/terminfo@0.5.11-0.151015 Well, -gate ships its own curses, and it's not exactly compatible with ncurses from what I understand. > But it is the one searched by software (and no fallbacks to other > locations). For example, trussing that "mc" call I see: mc is also not shipped by OmniOS AFAIK. 'vim' for me is searching /usr/gnu/share/terminfo correctly, not even stat()ing anything under /opt. Maybe you need to look at whoever shipped your mc? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS backup box hanging regularly
On Tue, Oct 27 2015 09:49:40 +0100, Jim Klimov wrote: > So far I use a mix of 'standard' time-slider and additionally my script that > kills oldest snapshot groups (chosen by pattern of automatic snaps) to keep a > specified watermark of free space. Yeah, we were previously using zfs-auto-snap from OpenSolaris before it became time-slider (with one or two local patches). > Something in this simple activity is enough to bring the box down into > swapping until the deadman knocks to interrupt the infinite loop looking for > a free page, and I've got a screenshot to prove this theory ;) In your previous mail you have a 'top' listing with way too many 'zfs' processes owned by zfssnap, and all are hundreds of megabytes in RSS. That sounds like a problem. IIRC, one problematic configuration that caused issues like this was a single filesystem setting a zfs-auto-snapshot property locally in a large tree where it also inherited it from the parent. My memory on this is a bit hazy though. > I wonder why doesn't the offending process die on some failed malloc... Good question. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS backup box hanging regularly
On Tue, Oct 27 2015 12:05:31 +0100, Jim Klimov wrote: > Heh, in fact this OmniOS installation does not offer a time-slider, but > rather the ksh93-based scripts for 'zfs/autosnapshot'. Now gotta verify what > i run elsewhere;) I think OmniOS ships neither time-slider nor zfs-auto-snapshot. When we used it I had to dig it out from somewhere in the interwebs and package it :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS backup box hanging regularly
On Fri, Oct 23 2015 18:54:27 +0200, Jim Klimov wrote: > 23 октября 2015 г. 11:23:28 CEST, Jim Klimov <j...@cos.ru> пишет: > >So at the moment it seems there is some issue with zfs-auto-snapshots > >on OmniOS that I haven't seen in SXCE, OI nor Hipster. Possibly I had > >different implementations of the service in these different OSes (shell > >vs python, and all that at different versions). I highly recommend znapzend for automatic snapshotting. We used to use an implementation called zfs-auto-snapshot (I wonder how many there are :) in the past but it was doing dumb things like listing all existing snapshots quite frequently, and that ate up memory. http://www.znapzend.org/ -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4
On Fri, Oct 23 2015 09:44:58 +0300, Lauri Tirkkonen wrote: > On Fri, Oct 23 2015 01:20:16 +0200, Volker A. Brandt wrote: > > It's been a while since I last tried, but I think this will not work, > > at least not in some corner cases, e.g. when the pkg is not installed > > at all > > I don't know about when pkg is not installed (how would you even update > or install the package then?) Sorry, looks like I failed at reading comprehension (I missed the "the" in "the pkg"). -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS backup box hanging regularly
On Thu, Oct 22 2015 20:51:32 +0200, Jim Klimov wrote: > Did anyone run into issues with many zfs-auto-snapshots (e.g. > thousands - many datasets and many snaps until they are killed to keep > some 200gb free) on a small nujber of spindles? Not with that number of snapshots, but we had several thousand filesystems with dozens (I think about 70) of snapshots per fs, and it turned out to be a really bad idea due to the memory requirements: things slowed down *a lot*. We didn't see any hangs though. I have a pool with around four thousand snapshots total at home and that box is performing just fine, and it's just two spinning disks + two SSDs for cache/slog. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4
On Thu, Oct 22 2015 20:57:45 +0200, Volker A. Brandt wrote: > Thanks for all the work you're doing on OmniOS! > > > > On Oct 22, 2015, at 1:11 PM, Dan McDonald <dan...@omniti.com> > > > wrote: > > > > > > "pkg update" followed by "svcadm restart ntp" as a safety measure > > > should be sufficient. No rebooting is needed. > > > > I made a small mistake here. The "svcadm restart..." is not > > necessary, the IPS package does the right thing here. > > Well, no, it doesn't. :-) That's due to a design flaw in the interaction > between IPS and SMF (IMHO). Even though the manifest object in the package > is properly tagged with restart_fmri, the service is never restarted, > because the manifest is not touched during the "pkg update", as it has not > changed since the last package version. > > So if you change an SMF method in a package and want an "automatic" > restart, you need to also physically modify the SMF manifest. I do that > by just incrementing a version counter or a timestamp, and noting the > fact in an XML comment in the manifest. Otherwise, you need to manually > restart the service. Well, that's not a design flaw. Actuators are executed only when the action (eg. file) specifying them changes -- in other words, the packager should include restart_fmri actuators in file actions that are relevant for the service in question (eg. the ntpd binary at minimum). This ntp package does not contain *any* restart_fmri actuators for the ntp service: % pkg contents -mr pkg://omnios/service/network/ntp@4.2.8.4-0.151014:20151022T170026Z|grep restart_fmri file cb84fc718d7aa637c12641aed4405107b5659ab8 chash=8758e80d1b9738c35f2d29cdebceee2930cdfa3b group=bin mode=0444 owner=root path=lib/svc/manifest/network/ntp.xml pkg.csize=1649 pkg.size=4681 restart_fmri=svc:/system/manifest-import:default (sidebar: the manifest-import service is what imports service manifests into the SMF repository, which you need to do when you install a new service) If you wanted to restart ntp when any files in the ntp package change on update, you would need an actuator like 'restart_fmri=svc:/network/ntp:default' on *all* file actions delivered by the package. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] omnios-build perl
On Tue, Oct 20 2015 12:42:50 +0200, Richard PALO wrote: > thought I'd try to rebuild perl (for grins) on bloody > > > richard@omnis:/home/richard/src/omnios-build/build/perl$ tail -30 build.log > > Build Perl for SOCKS? [n] > > Try to use long doubles if available? [n] > > Checking for optional libraries... > > What libraries to use? [-lsocket -lnsl -lgdbm -ldl -lm -lpthread -lc] Doesn't happen on my bloody box. Perhaps you have gdbm.h available somewhere and perl picks it up? My perl build.log says: ~/omnios-build/build/perl % egrep '(gdbm\.h|What libraries)' build.log What libraries to use? [-lsocket -lnsl -ldl -lm -lpthread -lc] NOT found. What libraries to use? [-lsocket -lnsl -ldl -lm -lpthread -lc] NOT found. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Installing non-current kernels on OmniOS r151014?
On Tue, Oct 13 2015 14:35:08 -0400, Chris Siebenmann wrote: > I *think* that the required older versions (both of the kernel and > of drivers) are still available in the OmniOS repository. However, > I can't seem to coax 'pkg' to show them to me (perhaps because they > differ only in the timestamp, not in the version number that pkg stuff > normally shows) and so I'm not sure I can get pkg to install them. They are: % pkg list -vfa kernel FMRI IFO pkg://omnios/system/kernel@0.5.11-0.151014:20150929T225337Z i-- pkg://omnios/system/kernel@0.5.11-0.151014:20150914T195008Z --- pkg://omnios/system/kernel@0.5.11-0.151014:20150913T201559Z --- pkg://omnios/system/kernel@0.5.11-0.151014:20150818T161044Z --- pkg://omnios/system/kernel@0.5.11-0.151014:20150727T054700Z --- pkg://omnios/system/kernel@0.5.11-0.151014:20150417T182434Z --- pkg://omnios/system/kernel@0.5.11-0.151014:20150402T175237Z --- Downgrading a kernel package might not be so trivial, though. pkg will generally refuse to downgrade packages unless you give version numbers in 'update', and the dependencies generally involve lots more packages than just system/kernel. > In related news, is there an easy way to fish the full specific versions > of installed packages out of a non-current boot environment? (Or for > that matter from the current boot environment.) Mount the BE (beadm mount) and run 'pkg -R list -v'. For the current BE just 'pkg list -v'. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
We're sending nightly incremental replication snaphots of a large
filesystem tree (about 3900 filesystems) to a backup host. It's been
working mostly okay - we scrub the source pool every month and that
hasn't had any effect on the sends/receives. However, on Sep 21, I
upgraded the backup host from entire@11-0.151014:20150402T192159Z to
entire@11-0.151014:20150914T123242Z, and during the zpool scrub on the
source host at the start of October we got this:
Assertion failed: ilen <= SPA_MAXBLOCKSIZE, file
../common/libzfs_sendrecv.c, line 1706, function recv_read
It seemed a transient failure as I was at first unable to reproduce it,
but firing off another scrub on the source pool did cause it to happen
again the following night, when scrub was still running. I further
upgraded the backup host to the Sep29 151014 update (which apparently
didn't bump the 'entire' version), and it's still happening. The source
host is currently in production and still running omnios-170cea2 (or
entire@11-0.151014:20150402T192159Z); we're scheduled to upgrade it next
Monday. It had a cache device up until Dan's recent advice to remove it;
I suspected maybe we'd been hit by corruption, but that doesn't explain
why the assertion happens only when the source pool is scrubbing.
We use this kind of command to send snapshots to the backup host:
zfs send -R -i $yesterday ${filesystem}@today | ssh backuphost zfs recv -ud
$targetfs
We're not running either send or recv as root, opting to use delegations
instead. Don't know if that's relevant or not.
Any clues?
--
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkg verify failing on pyc files
On Thu, Oct 08 2015 16:23:35 -0400, Eric Sproul wrote: > On Thu, Oct 8, 2015 at 3:37 PM, Lauri Tirkkonen <loth...@iki.fi> wrote: > > % pkg list -Hv simplejson-26 > > > > pkg://omnios/library/python-2/simplejson-26@3.6.5-0.151014:20150402T184431Z > > i-- > > > > Yes, yes it is, and it *was* built using pkgsend -T '*.py'. However, > > the commit in omnios-build introducing that was authored on Mar 25 2015 > > (8cc8f3ef45d9c7d8ccdfda608d00599cd3890597). My theory is that if the > > file content does not change, even if pkgsend -T is used to preserve the > > timestamps, the file is not touched on update; would that help explain > > what you're seeing? > > Since .pyc files are evidently locally modified outside of pkg(5), > would it make sense to mark them as such in their manifests, i.e. > setting the "preserve" attribute? This makes pkg verify not report > differences from the installed manifest. > > Perhaps not a total win, though, as it would mean potentially losing > upgrade content, unless preserve was set to "renameold" or some such. One could just not ship them at all; I was just trying to find out why they're being regenerated after the package install. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkg verify failing on pyc files
On Thu, Oct 08 2015 18:56:51 +0100, Peter Tribble wrote: > That's all correct. The packages appear to have been published using > pkgsend -T so > that the timestamps on the .py files are preserved, and they match the > timestamps > encoded into the packaged .pyc files.. > > Which makes me wonder even more why it's found it necessary to recompile > the files, it's not the normal python version or source timestamp mismatch. I think I found a clue for this. I checked an old box I've upgraded through multiple releases and sure enough, .pyc files had been regenerated after install for, among other things, the simplejson-26 package. I checked the timestamps for one such .py/.pyc pair: -rw-r--r-- 1 root bin 1036 Jul 22 2014 /usr/lib/python2.6/vendor-packages/simplejson/compat.py -rw-r--r-- 1 root root2040 Apr 3 2015 /usr/lib/python2.6/vendor-packages/simplejson/compat.pyc But this is strange - surely the package is newer than July 2014 on this 151014 box? % pkg list -Hv simplejson-26 pkg://omnios/library/python-2/simplejson-26@3.6.5-0.151014:20150402T184431Z i-- Yes, yes it is, and it *was* built using pkgsend -T '*.py'. However, the commit in omnios-build introducing that was authored on Mar 25 2015 (8cc8f3ef45d9c7d8ccdfda608d00599cd3890597). My theory is that if the file content does not change, even if pkgsend -T is used to preserve the timestamps, the file is not touched on update; would that help explain what you're seeing? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Thu, Oct 01 2015 13:49:03 +0200, Richard PALO wrote: > Le 01/10/15 11:58, Lauri Tirkkonen a écrit : > > On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote: > >>>> In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better > >>>> in > >>>> this case (or would OI not honour that setting correctly)? > >>> > >>> It wouldn't work. From what I can tell, those ndd settings only affect > >>> the SYN segments (ie. timestamp negotiation); pre-5850 illumos will > >>> always stop timestamping mid-connection if it receives a non-timestamped > >>> segment. > >>> > >> > >> Okay, I set tcp_tstamp_if_wscale to 0 and it does seem to work fine. > > > > Thanks, that pretty much confirms the issue is what I suspected it is. > > > >> (Hoping there isn't any fallout from doing this now...) > > > > As long as that middlebox has been mucking with your traffic in the way > > it is, timestamps have been getting turned off mid-connection for your > > pre-5850 box. I recommend you to ugprade to post-5850 if you can, or to > > scream loudly at whoever is modifying your traffic :) > > > > Actually I still notice some problems.. This morning in the direction OI => > omnios > things seemed okay. > Now, omnios => OI I just now experienced the hang again, and it is repeatable. > > Could it be that your workaround is only useful for outbound connections > (relative to OI)? Yeah, it's possible. Whoever sends the SYN expresses their capability to timestamp by including the tsopt, and you can disable that with the ndd options. I assumed that the ndd options would affect SYNACK as well, but I didn't actually read the code; I guess that's not the case after all, so inbound connections still get timestamping negotiated. I don't have a workaround for this, sorry. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Thu, Oct 01 2015 14:29:32 +0200, Richard PALO wrote: > >> Actually I still notice some problems.. This morning in the direction OI > >> => omnios > >> things seemed okay. > >> Now, omnios => OI I just now experienced the hang again, and it is > >> repeatable. > >> > >> Could it be that your workaround is only useful for outbound connections > >> (relative to OI)? > > > > Yeah, it's possible. Whoever sends the SYN expresses their capability to > > timestamp by including the tsopt, and you can disable that with the ndd > > options. I assumed that the ndd options would affect SYNACK as well, but > > I didn't actually read the code; I guess that's not the case after all, > > so inbound connections still get timestamping negotiated. I don't have a > > workaround for this, sorry. > > > > Too bad. Naturally it isn't feasible to turn things off via ndd on omnios > for just one target. > Is there any way to do that differently? That is, for only one target (and > primarily ssh)? Not that I know of. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote: > >>In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better in > >>this case (or would OI not honour that setting correctly)? > > > >It wouldn't work. From what I can tell, those ndd settings only affect > >the SYN segments (ie. timestamp negotiation); pre-5850 illumos will > >always stop timestamping mid-connection if it receives a non-timestamped > >segment. > > > > Okay, I set tcp_tstamp_if_wscale to 0 and it does seem to work fine. Thanks, that pretty much confirms the issue is what I suspected it is. > (Hoping there isn't any fallout from doing this now...) As long as that middlebox has been mucking with your traffic in the way it is, timestamps have been getting turned off mid-connection for your pre-5850 box. I recommend you to ugprade to post-5850 if you can, or to scream loudly at whoever is modifying your traffic :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Wed, Sep 30 2015 09:56:47 +0200, Richard PALO wrote: > >To be clear, it's not implementing RFC 1323 (and not even *not* > >implementing 7323) that causes the issue. 1323 actually didn't specify > >what to do with non-timestamped segments on a timestamp-negotiated > >connection, and illumos pre-5850 did something very surprising which I > >doubt nobody else did (stop generating timestamps on all future > >segments), so I don't think you will be able to reproduce the hang with > >other operating systems, but you'll likely be able to see the unexpected > >non-timestamped segments in connections between other OSes as well (but > >I still can't be sure because I don't know what middlebox is injecting > >them or why :) > > > > In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better in > this case (or would OI not honour that setting correctly)? It wouldn't work. From what I can tell, those ndd settings only affect the SYN segments (ie. timestamp negotiation); pre-5850 illumos will always stop timestamping mid-connection if it receives a non-timestamped segment. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Tue, Sep 29 2015 12:19:09 +0200, Richard PALO wrote: > Since I'm not having any issues with netbsd (6.1), which seemingly is still > at rfc1323 > >richard@omnis:/home/richard$ ssh netbsd.org /sbin/sysctl net.inet.tcp.rfc1323 > >net.inet.tcp.rfc1323 = 1 > > I'd like to do some additional tests involving a non-illumos host as well > just to make sure. To be clear, it's not implementing RFC 1323 (and not even *not* implementing 7323) that causes the issue. 1323 actually didn't specify what to do with non-timestamped segments on a timestamp-negotiated connection, and illumos pre-5850 did something very surprising which I doubt nobody else did (stop generating timestamps on all future segments), so I don't think you will be able to reproduce the hang with other operating systems, but you'll likely be able to see the unexpected non-timestamped segments in connections between other OSes as well (but I still can't be sure because I don't know what middlebox is injecting them or why :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Mon, Sep 28 2015 16:20:03 +0200, Richard PALO wrote: > Le 28/09/15 15:46, Lauri Tirkkonen a écrit : > > On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote: > >> > >>> On Sep 28, 2015, at 8:15 AM, Dan McDonald <dan...@omniti.com> wrote: > >>> > >>> If 5850 is indeed the problem, you need to report this to the > >>> illumos developers list, including a deterministic way of > >>> reproducing it. > >> > >> I see you filed bug 6264, which is a good first step. Please make > >> sure you summarize the how-to-reproduce in it. > >> > >> I also wonder if you patch your oi_151a9 box with 5850, AND keep 5850 > >> on your OmniOS machine, whether or not this problem ALSO goes away. > >> After all, this fix specifically targets machines that drop > >> timestamps... > > > > If my analysis is correct (see the mail I sent to this thread > > previously), then applying 5850 to the oi_151a9 box will cause the issue > > to disappear -- both peers will then ignore the injected window change > > segment because it has no timestamps. Of course, it's possible that the > > middlebox won't like being ignored and might cause other failures (it > > could still inject RSTs, for example, since those are not required to > > have timestamps). > > > > If I experienced the issue, chances a great anybody else with oi_151a9 have it > as well in France as the OI machine is connected to an Orange (previously > known > as France Télécom) Business Services SDSL router and the Omnios box to a > Freebox (Free Télécom). It just occurred to me that if timestamp options don't get negotiated at all on the connection, both peers should be fine with this injection and continue to function. So as a workaround you could try disabling timestamps on the oi_151a9 box. I see the following ndd options: % ndd -get tcp ?|grep tstamp tcp_tstamp_always (read and write) tcp_tstamp_if_wscale (read and write) You could try setting those to 0 and see if that works around the hang (untested, so beware). This obviously turns off TCP timestamps, but how useful are they on the pre-5850 box anyway if your middlebox has been defeating their use all this time? :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Mon, Sep 28 2015 16:20:03 +0200, Richard PALO wrote: > Le 28/09/15 15:46, Lauri Tirkkonen a écrit : > > On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote: > >> > >>> On Sep 28, 2015, at 8:15 AM, Dan McDonald <dan...@omniti.com> wrote: > >>> > >>> If 5850 is indeed the problem, you need to report this to the > >>> illumos developers list, including a deterministic way of > >>> reproducing it. > >> > >> I see you filed bug 6264, which is a good first step. Please make > >> sure you summarize the how-to-reproduce in it. > >> > >> I also wonder if you patch your oi_151a9 box with 5850, AND keep 5850 > >> on your OmniOS machine, whether or not this problem ALSO goes away. > >> After all, this fix specifically targets machines that drop > >> timestamps... > > > > If my analysis is correct (see the mail I sent to this thread > > previously), then applying 5850 to the oi_151a9 box will cause the issue > > to disappear -- both peers will then ignore the injected window change > > segment because it has no timestamps. Of course, it's possible that the > > middlebox won't like being ignored and might cause other failures (it > > could still inject RSTs, for example, since those are not required to > > have timestamps). > > > > If I experienced the issue, chances a great anybody else with oi_151a9 have it > as well in France as the OI machine is connected to an Orange (previously > known > as France Télécom) Business Services SDSL router and the Omnios box to a > Freebox (Free Télécom). > > Any hint on how to determine which box is doing it (or both)? > If not, if I can ssh into someplace that is able to check... > perhaps even an ftp session? Well, seeing how we only know that neither peer is actually sending the non-timestamped segment, it could be any box along the path - I'd start with examining your routers. It's hard to say what exactly will trigger a repro without knowing what the middlebox is trying to accomplish by injecting this segment, but it might be beneficial to try to get a repro with a simple echo server or something like that, and then try to isolate the issue by trying different connection paths. You could also talk to your providers. It's unfortunate that this manifests in a regression like this, but it's a product of the previous incorrect behavior, an obnoxious middlebox doing unsanitary things, and us (illumos-gate) trying to do the right thing by following the RFC. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Thu, Sep 10 2015 11:28:12 +0200, Richard PALO wrote:
> Le 08/09/15 14:12, Dan McDonald a écrit :
> >
> >>On Sep 8, 2015, at 12:32 AM, Richard PALO
> >><richard-s783fymb3ccdnm+yrof...@public.gmane.org> wrote:
> >>
> >>before the traffic seemingly when things go sour... I notice a Window
> >>changed to 1024??
> >
> >Which side is advertising the window change again? And which side is
> >running -gate from 2ed96329a073f74bd33f766ab982be14f3205bc9 ?
> >
> >This thread has been paged out, so to speak, for long enough. Can
> >you give me the context of which machine is running what to explain
> >the context of the snoop file?
> >
> >Thanks,
> >Dan
> >
> Just for completeness, same histoire from the OI side, snoop and ssh
>
> here, 192.168.1.2 is smicro (oi_151a9)
> >e1000g0 192.168.1.1 255.255.255.255 00:12:ef:21:9c:f8
> >e1000g0 192.168.1.2 255.255.255.255 SPLA 00:30:48:f4:33:f0
> and 192.168.1.1 is an Orange Business Services SDSL router.
Are these captures both from the same connection? If so, there is
obviously a middle box modifying the traffic. On *both* ends, it looks
like the other end is sending an empty ACK requesting the window change
to 1024 (packet 41 in snoop.output, with dst 192.168.0.6, and packet 41
in snoop-OI.output, with dst 192.168.1.2). Both of these TCP segments
are missing the required timestamp options.
With the fix for 5850, illumos should never send a segment without
timestamps on a connection which has negotiated timestamps (this one
has, since they are present on previous segments). In addition, as part
of 5850, we follow the RFC recommendation to drop any arriving segments
*without* timestamps on a timestamp-negotiated connection [0]. This is
likely the reason why your use case worked before; the older behavior
was to stop generating timestamps altogether on a connection where any
received segment omits them, but that's the wrong thing to do. There is
a new dtrace probe 'tcp:::droppedtimestamp' which should fire whenever a
segment is dropped by this behavior. You could use that to verify my
speculation, eg.
# dtrace -n 'tcp:::droppedtimestamp { trace(probefunc); }'
should generate output when the connection hangs (and more information
about the connection is available in (tcp_t*)arg0).
Based on the data you have made available I believe this is an issue
with a middlebox injecting erroneous traffic into the TCP stream for
both peers. This injected segment is ignored by the box with the fix for
5850 appliec, but it causes the older illumos box to stop generation of
timestamps, after which all segments it sends are rejected by the newer
box.
Oh, and in the future, please post snoop capture files (from snoop -o);
it's much easier to find the desired information in those :)
[0]:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/inet/tcp/tcp_input.c#2878
--
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] strangeness ssh into omnios from oi_151a9
On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote: > > > On Sep 28, 2015, at 8:15 AM, Dan McDonald <dan...@omniti.com> wrote: > > > > If 5850 is indeed the problem, you need to report this to the > > illumos developers list, including a deterministic way of > > reproducing it. > > I see you filed bug 6264, which is a good first step. Please make > sure you summarize the how-to-reproduce in it. > > I also wonder if you patch your oi_151a9 box with 5850, AND keep 5850 > on your OmniOS machine, whether or not this problem ALSO goes away. > After all, this fix specifically targets machines that drop > timestamps... If my analysis is correct (see the mail I sent to this thread previously), then applying 5850 to the oi_151a9 box will cause the issue to disappear -- both peers will then ignore the injected window change segment because it has no timestamps. Of course, it's possible that the middlebox won't like being ignored and might cause other failures (it could still inject RSTs, for example, since those are not required to have timestamps). -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS Bloody update
On Mon, Sep 14 2015 23:46:11 -0400, Dan McDonald wrote: > There have been some fixes there, but I'm not sure if it's all there. > I do know one has to use --reject options to make a switch. > > Lauri "lotheac" Tirkkonen can provide more details. Also note - there > is an effort to replace sunssh with OpenSSh altogether. OpenSSH is installable in bloody with: pkg install --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server It's a bit unwieldy, but does work -- the rejects are necessary to tell the pkg solver that it's okay to uninstall those packages (and satisfy the dependencies with openssh ones instead). There's at least one more problem with this change, though, and that is that openssh seems to be the default in new installs. I'm discussing that with Dan, but I suspect it's going to be a blocker for backporting. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openssh on omnios
On Mon, Aug 10 2015 23:11:24 -0400, Dan McDonald wrote: There may be a fix in bloody that needs to get backported. Lauri -- you around? Not very much this week, but what do you need? I'd also like to see this backported :) -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openssh on omnios
On Tue, Aug 11 2015 09:57:55 -0400, Dan McDonald wrote: On Aug 11, 2015, at 2:33 AM, Lauri Tirkkonen loth...@iki.fi wrote: Not very much this week, but what do you need? I'd also like to see this backported :) I was curious if you knew of any barriers to simply cherry-picking these: [snip] ... for r151014? Not off the top of my head, no. Releasing does require publishing the new entire package as well as openssh, but no modifications to sunssh packages required, if memory serves (can't check until next week, phone-only for the time being). -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Newer pkg list -v no longer displays build version
On Wed, Apr 08 2015 14:39:20 -0400, Eric Sproul wrote: The updated pkg(5) in 014 changes the default format for versions in `pkg list -v` output. Previously, the format was: component,build-branch:timestamp now it appears to be: component-branch:timestamp Good catch, thanks for the heads up. The build version has also been removed from pkg info output (both the separate line as well as the version in the FMRI). I'm also interested in the history; pkg(5) does still document that the build version is part of the FMRI. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Who alters /etc/profile or /etc/.login on their boxes?
On Fri, Feb 27 2015 16:27:18 -0500, Dan McDonald wrote: This is a serious question. A recent illumos push mildly affects people who have, but in OmniOS's case, it's a mild change (not a horrible one). Which one, and how? I'd appreciate some on-list feedback about who does and doesn't change their /etc/profile or /etc/.login vs. what we ship. I would expect very nearly everyone to change them. That's why they're in /etc, right? The next bloody update (and r151014) will alter the default file, and because of IPS, it won't be replaced IF the file was altered from the stock configuration. Fortunately for OmniOS, it's mostly a don't-care. Sure - as I understand it, this is how user-modifiable configuration files are normally handled with IPS. What's the problem behind the seriousness? -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] omnios-build broken
On Wed, Jan 21 2015 20:08:04 +0100, Michael Rasmussen wrote: 1) git clone https://github.com/omniti-labs/omnios-build.git 2) git checkout -b r151006 You cloned the repository and created a new branch called r151006 from the currently checked out branch, which would be master. Try checkout without -b at this point instead. 3) git branch --set-upstream-to=origin/r151006 r151006 4) git pull ... and then tried to merge origin/r151006 into it. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] PERL modules as packages conflict
On Tue, Jan 20 2015 11:14:46 -0500, Zach Malone wrote: I just published https://github.com/omniti-labs/omnios-build-perl to github. Hopefully that helps you with having a framework for building perl packages. Oh, nice! I only wish this had been available sooner -- I've made something similar, if a lot more rudimentary (and probably buggier): https://github.com/niksula/omnios-build-scripts/tree/master/perl-modules -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openldap-server install problems
On Wed, Jan 21 2015 03:30:48 +0100, Michael Rasmussen wrote: While building python-ldap I discovered that your openldap package is a 32 bit build and I was wondering if you intend to make a 64 bit package? The reason for your 32 bit build (https://www.illumos.org/issues/4215) is in state resolved and has been since 2014-16-10 so I should mean this has been fixed in 151006. But it hasn't. The commit listed in that ticket is 9048537, and: gutsman /gutsman/ws/illumos-omnios % git branch -a --contains 9048537 * master r151012 remotes/origin/HEAD - origin/master remotes/origin/master remotes/origin/r151008 remotes/origin/r151010 remotes/origin/r151012 remotes/origin/upstream You can see it's not in 151006, so that's why. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openldap-server install problems
On Mon, Jan 19 2015 18:29:28 +0100, Michael Rasmussen wrote: Would it be difficult to make a 2.6 version? PS. I have no knowledge of pkg package format. Not very - likely it'd be sufficient to modify or remove this line from the build script: https://github.com/niksula/omnios-build-scripts/blob/master/radicale/build.sh#L40 Although I'll leave setting up a build environment as an exercise to the reader. http://omnios.omniti.com/wiki.php/Packaging#How-tos See: http://radicale.org/user_documentation/#idpython-versions-and-os-support Ah, ok. You'd also need to install those extra libraries, just building against python2.6 isn't sufficient. -- Lauri Tirkkonen | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openldap-server install problems
On Sun, Jan 18 2015 23:44:52 +0100, Michael Rasmussen wrote: But the are for 151006 only? depend fmri=pkg:/system/library@0.5.11-0.151006 type=require They are built on 151006, but they can be installed on later releases because they don't have incorporate dependencies, and can even work thanks to binary compatibility. At work we still run LTS, but I am running quite a few packages at home on 151012 too. Of course, no guarantees :) -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Caldav suggestions?
On Sun, Jan 18 2015 02:02:45 -0500, Dan McDonald wrote: I'm surveying Caldav servers. Most require PHP, which bothers me from a security POV. Am I being overly harsh on PHP? Are there ones that don't require PHP? I'm running radicale at home, and have packaged it for OmniOS in the niksula.hut.fi repo. http://radicale.org/ -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Caldav suggestions?
On Sun, Jan 18 2015 13:57:22 -0500, Dan McDonald wrote: Wow! This may be a winner. How nicely does it play with iOS and MacOS? I don't use either of those so I can't offer any anecdotes on that, sorry. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openldap-server install problems
On Sun, Jan 18 2015 20:49:17 +0100, Michael Rasmussen wrote: I just fund this on github: https://github.com/niksula/omnios-build-scripts/tree/master/openldap Can this be used? And how to use? @Lauri Is this your build tree? Yes, I maintain those scripts as well as the binary repository at http://pkg.niksula.hut.fi/ - this is also mentioned at http://omnios.omniti.com/wiki.php/Packaging -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgdepend reports unresolved dependencies
On Wed, Jan 07 2015 23:19:50 +0200, Lauri Tirkkonen wrote: pkgdepend is telling you that the runtime linker can't find libdovecot.0.0.0 And that's a typo - I meant libdovecot.so.0. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgdepend reports unresolved dependencies
On Wed, Jan 07 2015 12:52:14 -0500, Alex McWhirter wrote: /tmp/build_locadmin/triadic_service_pigeonhole.p5m.int.3 has unresolved dependency ' depend type=require fmri=__TBD pkg.debug.depend.file=libdovecot.so.0 \ pkg.debug.depend.reason=opt/triadic/lib/amd64/dovecot/libdovecot-sieve.so.0.0.0 \ pkg.debug.depend.type=elf \ pkg.debug.depend.path=lib/64 \ pkg.debug.depend.path=opt/triadic/lib/amd64 \ pkg.debug.depend.path=usr/lib/64'. Okay, so the pkg.debug.depend.file (libdovecot.so.0) cannot be found by pkgdepend. pkg.debug.depend.reason points to what needs that file (because the latter links to the former). You were able to build it successfully, so obviously you linked to the correct library, but pkgdepend is telling you that the runtime linker can't find libdovecot.0.0.0 (this would probably bite you at runtime too). I solved exactly this problem by building pigeonhole with rpath appended so that libdovecot.so.0 could be found: https://github.com/niksula/omnios-build-scripts/blob/master/pigeonhole/build.sh#L43 -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] KVM within a child zone
On Tue, Dec 23 2014 19:28:47 +1000, Michael Mounteney wrote: That gets it a bit closer but I still need the real interface (e1000g1) for vnc and sshing in etc. and I can't give that to the zone exclusively. You can create a vnic over your physical interface (with dladm(1M)) and then give that to the zone. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: Ang: Re: KVM and SMF
On Thu, Nov 06 2014 12:35:35 +0100, Jorge Schrauwen wrote: I use transient for my script that start qemu. By default if the process does not daemonize it is killed after... I think 90 seconds by default. svc.startd(1M) manual mentions: If a contract or transient service does not return from its start method before its defined timeout elapses, svc.startd sends a SIGKILL to the method, and returns the service to the offline state. and Defining a service as transient means that svc.startd does not track processes for that service. Thus, the potential faults described for contract model services are not con- sidered failures for transient services. Because of these I would use 'contract'. If your start method does not daemonize, you can just add a '' at the end of start/exec. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: KVM and SMF
On Thu, Nov 06 2014 13:13:19 +0100, Johan Kragsterman wrote: Do you mean that I should just change the transient to contract? Yes, or you can leave the definition out, since 'contract' is the default. And the at the end of start/exec like this: exec_method type='method' exec='/usr/bin/vmpfsense.sh' name='start' timeout_seconds='120' / No. exec_method exec=/usr/bin/vmpfsense.sh ... / or so in XML. You can also set the properties via svccfg without having to much around with XML. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgsend generate bug with spaces in file names
On Tue, Nov 04 2014 13:35:39 +, Al Slater wrote: I have run into the same problem while packaging cmake. Is there a solution? I have an open pull request for this, but from what I understand OmniOS' pkg isn't currently in a state where they can merge it. The OmniTIers can probably elaborate on that, but if you want to apply the patch yourself, it's at https://github.com/postwait/pkg5/pull/4 -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] openldap-server package out of sync?
On Thu, Oct 02 2014 18:15:10 +1000, Michael Mounteney wrote: No suitable version of required package pkg://ms.omniti.com/omniti/network/openldap-server@2.4.40,5.11-0.151006:20140930T201405Z found: Reject: pkg://ms.omniti.com/omniti/network/openldap-server@2.4.40,5.11-0.151006:20140930T201405Z Reason: A version for 'incorporate' dependency on pkg:/entire@11,5.11-0.151006 cannot be found Here's how this reads: the package from ms.omniti.com cannot be installed because it constrains 'entire' to 11,5.11-0.151006. This is because, as far as I know, OmniTI builds their managed services (omniti-ms) packages only for LTS, and they add incorporate dependencies to prevent the packages from being installed on newer releases. Any ideas ? OpenLDAP is also available in the repo that I maintain (http://pkg.niksula.hut.fi/). While it doesn't constrain entire to 151006 like omniti-ms packages do, the packages have been built in 151006 and I make no guarantees about them working on any release, but of course welcome pull requests ;) All that said, per KYSTY (http://omnios.omniti.com/wiki.php/KYSTY) it might be a good idea to build packages you want yourself to avoid being constrained by someone else's idea of what version you should get. This is pretty easy to do by forking omnios-build and pulling ready-made build scripts from the available repositories. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151012 is coming...
On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: What I'd like to know now is: Any updates you need/want in r151012? Since you asked - how about this? :) https://github.com/postwait/pkg5/pull/4 -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Install issues
On Sun, Aug 24 2014 09:04:39 -0400, Scott LeFevre wrote: Reject: pkg://omnios/entire@11,5.11-0.151008:20131205T195242Z Reason: All versions matching 'require' dependency pkg:/library/python-2/pycurl@7.19.0.1,5.11-0.151008 are rejected Reject: pkg://omnios/library/python-2/pycurl@7.19.0.1,5.11-0.151008:20131204T024248Z Reason: All versions matching 'require' dependency pkg:/web/curl are rejected Reject: pkg://omnios/web/curl@7.32.0,5.11-0.151008:20131204T025214Z pkg://omnios/web/curl@7.33.0,5.11-0.151008:20131205T191134Z Reason: Newer version pkg://omnios/web/curl@7.36.0,5.11-0.151006:20140414T214024Z is already installed Reject: pkg://omnios/web/curl@7.36.0,5.11-0.151006:20140414T214024Z pkg://omnios/web/curl@7.36.0,5.11-0.151008:20140414T215242Z Reason: Excluded by proposed incorporation 'incorporation/jeos/omnios-userland' Reject: pkg://omnios/library/python-2/pycurl@7.19.0.1,5.11-0.151008:20131205T191236Z Reason: All versions matching 'require' dependency pkg:/web/curl are rejected The trouble here is that r151008 does not include curl 7.36, but 151006 does (and you have that version installed, so pkg refuses to downgrade it without you asking). I think this is a packaging bug in 151008. I believe I worked around this by 'pkg update curl@7.33' when I upgraded. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] how to see the real process arguments
On Wed, Aug 13 2014 09:12:27 +0200, Tobias Oetiker wrote: I thought pargs was going to show me the arguments It prints the contents of argv, but the program may have modified it. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] omnios-build: the build system, scripts and merging between branches
Please read this and comment if you maintain a fork of omnios-build.
Thanks.
Status quo
--
The omnios-build repository currently versions more than one thing:
- the build scripts which describe how to build certain software (under
build/),
- the build system (lib/ (mostly), build/buildctl and template/)
- and some site-specific data (configuration).
The 'template' branch holds nothing site-specific and users are expected
to fork that one, adding their own stuff on top and pulling changes from
upstream's 'template'. This works in one direction, but in practice the
workflow is not make your changes on top template; it needs to work in
both directions. When the build scripts and configuration are in the
same repository, you cannot merge back into template - you must instead
be careful with cherry-picking. This isn't very maintainable: recently I
made a pull request that just ported build system changes from
omniti-labs:master to omniti-labs:template and that was 176 commits in
size (ie. after pruning all commits which only touched build scripts).
I maintain two forks of omnios-build (one for a publicly available repo,
and one for a private one) and syncing changes between them and upstream
is a royal pain. I'd wager OmniTI isn't particularly fond of porting
build system changes between different release version branches and
omniti-ms and friends.
I argue that making build system changes flow from one fork/branch to
another needs to be made easier. The way to do that is to split the
build system from the build scripts into another repository, so that
merges can be made freely. This obviously requires some rather large
changes, which I will propose below.
Proposal: submodules?
-
At first, I was thinking git submodules are the solution to this. If
you're not familiar, submodules are a way to include a reference to
another repository at a certain commit. This is the sort of tree I was
thinking about:
omnios-build-my-organization (your site-specific build repo)
|-- lib (submodule: the build system, or: site-independent code)
|-- build
`-- (config.sh, site.sh and other site-specific data)
This would allow you to work on lib/ separately from your build scripts,
and make it clear which version of the build system they need to build.
However, git submodules are a bit unwieldy and not very intuitive (among
other things you need to manually use submodule commands to update the
submodule tree instead of git doing it for you; this is certain to get
annyoing when switching branches).
Better proposal
---
So, let's make this simpler by turning it around and ditching the
submodule idea. Let's just have omnios-build contain site-independent
data (ie. the build system), and make build/ another repository, but
let's not make it a submodule. Instead, .gitignore it and make ./new.sh
warn and initialize a new git repository into it if it doesn't exist.
This doesn't require any submodule trickery, but lets you have your
scripts in a separate repo.
Proof of concept is on github niksula/omnios-build split branch and
niksula/omnios-build-scrips repos:
git clone -b split https://github.com/niksula/omnios-build.git
cd omnios-build
git clone https://github.com/niksula/omnios-build-scripts.git build
cd build/ircii
./build.sh
In the PoC I moved buildctl out of build/ and {site,config}.sh inside it
(to the omnios-build-scripts repo). It's not a finished product, but
should demonstrate what I'm saying.
Thoughts?
--
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] omnios-build: the build system, scripts and merging between branches
On Mon, Jul 07 2014 12:02:59 -0400, Dan McDonald wrote: This *seems* sensible, especially as you've put buildctl at the top-level in the omnios-build half of the split. It seems right now, however, that buildctl still assumes it's in build/. instead of one directory above it. Yep, it does. As I said, it's just a PoC at this point (but I think you might be able to do 'cd build; ../buildctl'. I don't use buildctl myself, yet) It's also not 100% clear that the functions in lib/ have been altered to assume site.sh and config.sh are in build instead of lib. https://github.com/niksula/omnios-build/compare/niksula:master...split I'd like to see what all changed in any scripts that now live in the build half of your split vs. their original pre-split incarnations. Not sure if github or a tool like webrev would be able to help here. Nothing in the scripts themselves changed. I did a git filter-branch --subdirectory-filter to split the build dir into its own repo, after which I just removed buildctl, added config.sh and site.sh. The latest three commits at https://github.com/niksula/omnios-build-scripts/commits/master basically. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] trouble building DBD::mysql (perl)
On Wed, Jun 18 2014 22:48:43 +0200, Natxo Asenjo wrote: Is there a 64bit system perl? I do not see it in /usr/bin/amd64/perl like for python2.6. pkg://omnios/runtime/perl-64 -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] restore zones after crash
On Mon, Jun 09 2014 12:19:58 +0200, Natxo Asenjo wrote: cannot set property for 'tank/zones/zone1/ROOT/zbe-5': 'mountpoint' cannot be set on dataset in a non-global zone zfs set zoned=off might help here. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] compiling mediatomb #error non-amd64 code depends on amd64 privileged header!
On Sun, May 11 2014 21:57:26 +0200, Natxo Asenjo wrote: # grep m64 Makefile CFLAGS = -g -O2 -m64 Or should I do it differently? I am not really sure ... It depends on the build system of the software you're trying to build. Your make output before included g++, so it is likely that you need to add -m64 to CXXFLAGS as well. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] pkgsend generate bug with spaces in file names
I ran into this while packaging Python 3.4.0 which apparently ships files with space characters in them. % mkdir foo touch 'foo/bar baz' % pkgsend generate foo | pkgmogrify pkgmogrify: File stdin line 1: Malformed action at position: 12: file bar baz group=bin mode=0644 owner=root path=bar baz ^ http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gludq suggests this has has possibly been fixed in Oracle's pkg. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] How do you configure serial ports on OmniOS?
On Fri, Feb 28 2014 13:16:45 -0500, Chris Siebenmann wrote:
This question makes me feel silly but I'm lost in a confusing maze of
documentation for sacadm, pmadm, and so on and I can't find anything
with web searches. What I would like to do is configure what I believe is
/dev/term/c ('ttyS3' in Linux) to run a getty or the OmniOS/Illumos/etc
equivalent at 115200 baud.
I found this pretty useful:
http://iws.cs.uni-magdeburg.de/~elkner/keyboard/serialconsole.txt
(Please note that I do not want to make this the serial console, a
procedure for which there seems to be plenty of documentation. I just
want to be able to log in over that serial port, or it and /dev/term/a.)
Right, so skip setting console stuff; sttydefs and a console-login
service instance should do it I believe.
--
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Set locale in zone
On Wed, Jan 29 2014 12:35:26 +0100, Christian Flaig wrote: I'm still on r15006, will migrate/re-install soon. I've created a new zone, and can't set the locale from C to en_GB.UTF-8 for that zone. The global zone has this setting, but I haven't found out how to configure it (in non-global zone) or where it is configured (global zone). I've tried the following: (1) /etc/default/init According to several instructions on the web, this is the place where I should put my locale configuration. I can define all the variables, but the system doesn't take them (command locale still shows C). This works for me. You probably need to restart the zone for changes to take effect though. Tested as follows: # pargs -e $(pgrep -z kekkonen svc.startd) 5193: /lib/svc/bin/svc.startd envp[0]: _=*5088*/lib/svc/bin/svc.startd envp[1]: LANG=en_US.UTF-8 envp[2]: LC_TIME=C envp[3]: PATH=/usr/sbin:/usr/bin envp[4]: PWD=/ envp[5]: SHLVL=1 envp[6]: TZ=Europe/Helsinki envp[7]: A__z=*SHLVL -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] system/fm/smtp-notify mailing about already-resolved events on boot
smtp-notify seems to be generating emails for every recorded diagnosed event upon system boot, even when those faults have been repaired or resolved long since. We're on r151006. This seems like a bug - is anyone else seeing this? -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kayak bugs, r151008j
On Wed, Jan 15 2014 09:24:48 -0500, Theo Schlossnagle wrote: patches welcome. The access.log is generated via the anonymous dtrace script: anon.dtrace.conf (check the makefile for more info). Also, someone is welcome to try to run a new install with the anonymous dtrace function and catch the access.log. It's a bit more work, but it hasn't been done since 151002. I gave this a shot using r151006, but I might be missing something since the file grew quite a bit: data/access.log | 3869 +-- 1 file changed, 2421 insertions(+), 1448 deletions(-) I just ran the installation with NO_REBOOT=1 and consumed the data with dtrace -ae in a shell afterwards. The output format generated by dtrace here also seems different from the existing access.log -- the former includes a third field (fi_mount). Maybe the dtrace script should be modified to generate matching output (and probably drop the stuff from under /mnt)? -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kayak bugs, r151008j
On Mon, Jan 20 2014 17:52:40 +0200, Lauri Tirkkonen wrote: On Wed, Jan 15 2014 09:24:48 -0500, Theo Schlossnagle wrote: patches welcome. The access.log is generated via the anonymous dtrace script: anon.dtrace.conf (check the makefile for more info). Also, someone is welcome to try to run a new install with the anonymous dtrace function and catch the access.log. It's a bit more work, but it hasn't been done since 151002. I gave this a shot using r151006, but I might be missing something since the file grew quite a bit: data/access.log | 3869 +-- 1 file changed, 2421 insertions(+), 1448 deletions(-) Answering to myself - while I did check that /mnt did not account for all of the additions I didn't consider other filesystems like /proc :) % grep -c ' /$' data/access.log 1187 I will make a PR soonish but there probably needs to be separate access.log files for different releases. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kayak bugs, r151008j
On Mon, Jan 20 2014 17:10:14 +, Sean Doran wrote: Incidentally, the kayak process works fine with iPXE instead of pxegrub, with one big gotcha, namely that pxegrub gunzips miniroot.gz whereas iPXE does not have that functionality (yet). The kernel can’t itself deal with a compressed miniroot and promptly crashes. Given how much better http is than tftp is in almost every way, and ditto iPXE over pxegrub, having an uncompressed miniroot (at ca. 148M rather than 44M) kicking around in /var/kayak/kayak doesn’t seem too awful. Hmm, thanks for the heads up, I might try this at some point. We are using grub2 for our netboots, which also supports http, but based on one test the implementation seems to be just as slow as tftp. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kayak bugs, r151008j
On Tue, Jan 14 2014 15:54:21 +, Sean Doran wrote: Thirdly, the miniroot’s /kayak/disk_help.sh will bomb at line 124: log Creating rpool with: zpool create -f rpool $ztype $ztgt zpool create -f rpool $ztype $ztgt || bomb Failed to create rpool” because zpool create complains about not being able to share rpool in the absence of shareadm(1M). I'm currently building a kayak miniroot of my own due to needing to include a non-redistributable NIC driver and also ran into this. The root cause is that libshare needs libxml2, which is dropped from the miniroot: in the kayak repo data/access.log includes a libxml2.so.2.9.0, but the current version is libxml2.so.2.9.1 and that gets dropped. I don't know how this 'access.log' was generated, but I'm thinking it should be regenerated :) -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem installing new zone (version problem)
On Wed, Jan 08 2014 13:45:04 +0100, Martin Dojcak wrote: in non-global zone: cat /etc/release OmniOS v11 r151008 Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. This is probably due to omnios-userland not getting installed in the non-global zone. I think that was fixed with a new r151006 'entire' (which has a depend type=require on omnios-userland; earlier version did not actually make sure omnios-userland is installed) sometime in December, but you need to have that fix in your GZ because non-global zones are always installed with the same exact version of entire as the GZ. Or as a workaround, you can tell zoneadm to install the correct version of omnios-userland as an extra package (-e was the command line flag I think). -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem installing new zone (version problem)
On Wed, Jan 08 2014 20:57:42 +0100, Martin Dojcak wrote: I thnik omnios guys should fix pkg://omnios/entire@11,5.11-0.151006:20131210T224515Z and later versions with omnios-userland type=require. They already have: % pkg contents -rm pkg://omnios/entire@11,5.11-0.151006:20131210T224515Z|grep userland depend fmri=incorporation/jeos/omnios-userland@11,5.11-0.151006 type=incorporate depend fmri=incorporation/jeos/omnios-userland type=require Your issue was that your entire was older (and did not include this fix). -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Dell R720 Broadcom ethernet
On Thu, Dec 26 2013 20:12:18 +, Saso Kiselkov wrote: On 12/26/13, 8:10 PM, Saso Kiselkov wrote: On 12/26/13, 7:50 PM, Saso Kiselkov wrote: On 12/26/13, 7:45 PM, Scott Roberts wrote: Saso, It has the following: Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter Total of (2) GigE and (4) 10Gb SFP+ ports. Sorry to disappoint, but those 10Gb parts aren't and probably never will be supported. Unfortunately, Broadcom has a bad habit of shipping binary blobs only, so there's no way we could even port over support from other platforms (as we're doing with Intel hardware). Minor correction here. It appears the tg3 Linux driver *is* open-source, so provided that you can get Broadcom to give it a liberal-enough license to let us include it in Illumos, you might be able to port it to Illumos. FreeBSD, which is the source of many drivers that Illumos ports over, sadly, doesn't seem to support it either. Damn, correction #2 here: FreeBSD does include support for this since 10-current, so its bxe(4) driver is a potential target for porting: http://www.freebsd.org/cgi/man.cgi?query=bxeapropos=0sektion=4manpath=FreeBSD+10-currentarch=defaultformat=html Now just to find the person with enough spare time on their hands to do the actual grunt work... Interestingly, Broadcom's GLDv3 driver package for these cards from http://www.broadcom.com/support/license.php?file=NXII_10/solaris_ev-7.8.11.zip includes the source code and even has an illumos compilation target (but no illumos binaries). We tried at work and the driver attaches to our 57810 NICs, but we haven't tried actually using them yet. The license doesn't seem very permissive though... -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151008 ipkg zone attach problems
On Sat, Dec 07 2013 18:52:59 +0200, Lauri Tirkkonen wrote: I noticed that I could not attach my non-global zones under r151008 after upgrading from r151006. I made a couple VMs to reproduce, and it turns out that ipkg zone attach is broken on r151008 even on a fresh install Just a heads up - this is still broken on r151008f. Should I make a bug report on the tracker? -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage.
On Sun, Dec 08 2013 07:46:30 -0500, Bryan Horstmann-Allen wrote: +-- | On 2013-12-08 13:01:35, Lauri Tirkkonen wrote: | | I believe this isn't enough, since the zone install only installs | entire. It would work if entire depended on omnios-userland, but in the | meantime you could use 'zoneadm -z test1 install -e omnios-userland' | which makes sure omnios-userland is also installed in the zone. What's interesting here is... even if I'm very explict about which entire to install: # zoneadm -z test3 install -e entire@11,5.11-0.151006:20130507T204959Z entire is always installed matching the gz AFAIK, the -e option specifies extra packages to install, and you need omnios-userland. Try that. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] r151008 ipkg zone attach problems
-userland@11,5.11-0.151008:20131205T223747Z
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151008:20131206T160517Z
Reason: This version is excluded by installed incorporation
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151006:20131030T205312Z
[December 7, 2013 06:12:55 PM UTC] ERROR: Could not update attaching zone
[December 7, 2013 06:13:00 PM UTC] Result: Attach Failed.
Which looks like it's only trying to update entire, not omnios-userland.
But it's weird, because entire has these dependencies:
depend fmri=incorporation/jeos/omnios-userland@11,5.11-0.151008 type=incorporate
depend fmri=incorporation/jeos/omnios-userland type=require
Just guessing here, but perhaps the require dependency needs to have an
explicit branch version as well?
An explicit 'pkg -R /zones/ngz/root update entire@latest
omnios-userland@latest' before attaching works around this (but not the
'unable to get preferred publisher information' issue).
--
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
diff --git a/src/brand/attach b/src/brand/attach
index e754c2c..a0e0abe 100644
--- a/src/brand/attach
+++ b/src/brand/attach
@@ -256,10 +256,8 @@ get_preferred_publisher() {
for key in ${!publishers[*]}; do
eval publisher=${publishers[$key]}
- if [[ ${publisher.preferred} == true ]]; then
- print ${key}
- return 0
- fi
+print ${key}
+return 0
done
return 1
}
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] trouble mirroring the zpool rpool
On Mon, May 06 2013 20:36:33 +0200, Natxo Asenjo wrote:
But when I try the procedure in the openindiana wiki I get this:
# fdisk -B c15t0d0p0
# prtvtoc /dev/rdsk/c14t0d0s2 | fmthard -s - /dev/rdsk/c15t0d0s2
fmthard: Partition 2 specifies the full disk and is not equal
full size of disk. The full disk capacity is 61705665 sectors.
fmthard: Partition 2 specified as 61737795 sectors starting at 0
does not fit. The full disk contains 61705665 sectors.
fmthard: New volume table of contents now in place.
# zpool attach rpool c14t0d0s0 c15t0d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c15t0d0s0 overlaps with /dev/dsk/c15t0d0s2
Those devices refer to disk slices (hence the 's' at the end), and slice
number two refers to the entire disk by convention (but not necessarily;
for more information see
http://docs.oracle.com/cd/E19082-01/819-2723/disksconcepts-20068/index.html),
so it will overlap any other slice.
zpool is correct in warning you about this, but in many cases you might
just want to use the entire disk ('c15t0d0' should work). I'm not sure
whether you can do that with rpool disks though, since they need to boot
from somewhere.
--
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
