[oi-dev] Strange output during upgrade to the latest prestable
Hi, on one system I see this: Removal Phase73/3158 Warning - directory /tmp/tmppQR55O/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /tmp/tmppQR55O/var/pkg/lost +found/usr/share/man/cat1m-20120415T121445Z No idea why /usr/share/man/cat1m was delivered in previous prestable and not now. But the key question is - why it is printed with /tmp/tmppQR55O prefix and the content is not available neither in the current nor in the new BE? Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Strange output during upgrade to the latest prestable
Hi Milan, On 15 Apr 2012, at 11:52, Milan Jurik wrote: Removal Phase73/3158 Warning - directory /tmp/tmppQR55O/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /tmp/tmppQR55O/var/pkg/lost +found/usr/share/man/cat1m-20120415T121445Z We'll need to look into why cat1m has changed. Is /tmp/tmppQR55O not where the cloned boot environment was mounted for the pkg to operate on? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Strange output during upgrade to the latest prestable
Hi Milan, I've just checked, and it's because the new OI prestable ships with a newer version of pkg which no longer delivers the cat1m file. The newer pkg version I believe is the S11 pkg version backport to S11X to facilitate upgrading between the two versions. It looks like cat1m/pkg.depotd.1m was moved into the package/pkg/system-repository package in S11 but the backport doesn't provide it. We might want to patch it back into being supplied for the actual stable build. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] samba security
Hi, yesterday I updated to oi_151a3 and saw: # pkg list | grep samba library/samba/libsmbclient3.5.5-0.151.1.3 i-- service/network/samba 3.5.5-0.151.1.3 i-- Is there any newer version without the security bug from https://www.samba.org/samba/security/CVE-2012-1182 ? Best regards, Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
A version of 3.6.4 is pending for the illumos-userland head. On Sun, Apr 15, 2012 at 1:44 PM, Martin Walter m...@uni-freiburg.de wrote: Hi, yesterday I updated to oi_151a3 and saw: # pkg list | grep samba library/samba/libsmbclient 3.5.5-0.151.1.3 i-- service/network/samba 3.5.5-0.151.1.3 i-- Is there any newer version without the security bug from https://www.samba.org/samba/security/CVE-2012-1182 ? Best regards, Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On 15 Apr 2012, at 13:54, Bayard Bell wrote: A version of 3.6.4 is pending for the illumos-userland head. Hi Walter, Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On Apr 15, 2012, Alasdair Lumsden wrote: Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. You may wish to reconsider... A remote, pre-authentication vulnerability is essentially the most severe kind of flaw that can crop up in a software package such as Samba. An attacker who found a vulnerable installation of Samba would not need to authenticate in order to launch an exploit. http://m.threatpost.com/en_us/blogs/remote-pre-authentication-flaw-fixed-samba-041112 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On Sun, Apr 15, 2012 at 02:18:11PM +0100, Alasdair Lumsden wrote: On 15 Apr 2012, at 13:54, Bayard Bell wrote: A version of 3.6.4 is pending for the illumos-userland head. Hi Alasdair, Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. pkg.openindiana.org/experimental is last updated at 2011-11-19 !? I think such critical security holes should be fixed asap. Otherwise it is really a risk to run Openindiana on big fileservers. Best regards, Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] userland history problems
I've got a cleaned up repo ready and will push it to the canonical later. A summary of changes: 1) this is based off the userland-gate/oi-build history (that's where revision 0 now starts) 2) the history has been made linear; for three out of four merges in the history, this was a no-op; for the fourth (rev 445 in the new history was previously part of a merge but is not an initial import of changes for the illumian build system, which still requires issue 2160/rev 448 for clean-up) 3) Nexenta copyrights were written twice to cpan2ips and py2ips; these have been de-duped (rev 464) 4) changes that were backed out (and obviously the backouts were removed, as these simply make for noise in a lot of places when trying to read back through annotations) 5) two userland-gate changes that were lacking a space separator between name and address in the user field have been fixed (revisions 359 and 404) 6) the one tag assignment subsequent to these changes has been altered to reflect the altered change signatures (build-170 assigned to rev 378 via rev 380) I've confirmed via hg fetch from the current illumos-userland and then hg-recommit that there are no unaccounted-for differences (the only differences are the difference in .hgtags resulting from signature differences and an extraneous line feed removed as part of the Nexenta copyright de-dup). I've also gotten peer review on the rebuild from andy_js. I'm going to confirm that everything is good to go for git by building hg-git/dulwich, importing, running git fsck, and pushing to github. The mirror on hg.oi.o will lag somewhat behind cleaning the canonical, as it will need to be stomped and re-cloned before mirroring can be resumed. At that point the illumos-infra folks can provide github mirroring for us. If you have clones out there for issues, what I'd suggest is waiting until there's an illumos/illumos-userland to clone from. Take what you've got in your issue clone, push it to bitbucket for backup (hg push ssh://h...@bitbucket.org/userid/illumos-userland-issue), export the changes (e.g. hg export -g -o ~/illumos-userland.issue tip--you will need to do this for additional revisions between the canonical tip and the local if you have multiple changesets for the issue), stomp the local repo (hg strip 0), re-path it to the canonical (edit .hg/hgrc off the top of the clone to set default = ssh://h...@bitbucket.org/illumos/illumos-userland), sync to the local clone (hg fetch; if you haven't enabled the fetch extension, add fetch = in the [extensions] section of ~/.hgrc), and then import your changes back in (hg import ~/illumos-userland-issue). Do an hg outgoing ssh://h...@bitbucket.org/illumos/illumos-userland to confirm that the changes you've imported all show up. Please note that ssh://h...@bitbucket.org/illumos/illumos-userland does not yet exist, and it shouldn't exist until the canonical's been sorted. Cheers, Bayard On Thu, Apr 12, 2012 at 11:12 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Bayard, Sorry for not getting back to you sooner - I think the answer is go for it. We only get this opportunity once, so lets take it. The hassle factor is worth it, checking out the tree again is trivial. Cheers, Alasdair On 12 Apr 2012, at 22:03, Bayard G. Bell wrote: Unless I hear any compelling objection, I'm going through with this this weekend. On Tue, 2012-04-10 at 18:51 +0100, Bayard G. Bell wrote: In the course of fulfilment of my request for git mirroring, I've learned that we have a slight problem in our history: someone forgot to put a space between their name and the angle brackets surrounding their e-mail address. There are two ways to fix this: one is to ask github to disable validation of this data, the other is to fix the history, which is a destructive change. Since we're just getting on our feet, I'm inclined to make two substantial clean-ups in the history, one is to fix these commit records, and the other is to remove backed out changesets so they don't show up in annotations (which seems reasonable, given that the net effect is that no change happened, which to my mind shouldn't have two records against it for most repository contents). That means everyone using illumos-userland will need to re-clone for both mercurial and git. I know it's ugly, but I think this is pretty much the last point at which we can bite the bullet and clean this up properly--the other option is a workaround, whereas this is a painful fix. On the plus side, we'll finally have mirrors of the canonical available as illumos/illumos-userland. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On Apr 15, 2012, at 7:11 AM, Martin Walter wrote: I think such critical security holes should be fixed asap. Otherwise it is really a risk to run Openindiana on big fileservers. That service should never be exposed to the Internet in the first place. But otherwise I'd agree it ought to be considered for inclusion since the Samba team has decided it important enough that they're also patching some end of lifed versions as well. -Gary ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On Sun, Apr 15, 2012 at 08:57:56AM -0700, Gary Driggs wrote: On Apr 15, 2012, at 7:11 AM, Martin Walter wrote: I think such critical security holes should be fixed asap. Otherwise it is really a risk to run Openindiana on big fileservers. That service should never be exposed to the Internet in the first place. Yes, of course. But 25000 internal users (students) are enough for me to feel uncomfortable with this bug! ;-) Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
Hi Martin, On 15 Apr 2012, at 15:10, Martin Walter wrote: snip Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. pkg.openindiana.org/experimental is last updated at 2011-11-19 !? I think such critical security holes should be fixed asap. Otherwise it is really a risk to run Openindiana on big fileservers. The binary repo was last updated quite a while ago, but work continues on the source side at: https://hg.openindiana.org/illumos-userland/ and https://hg.openindiana.org/upstream/oracle/userland-gate The challenge is manpower - 151a was built using a collection of highly unpalatable build systems that few of our developers want to work on. The reason for the delay between oi_151 and our next big release (not the stable) is that we're completely re-tooling around a single build system. Once done, we'll be able to churn out updates far more easily. However the retooling effort has been derailed and held up by the fact it started life as oi-build and became a collaborative effort with Nexenta called illumos-userland, which they are going to also use for Illumian. A lot of resources have had to be diverted to sorting out collaborating with them and dealing with the consequences of this. We're nearly there and hopefully things will speed up again once we get into the swing of things. If you'd like things to proceed faster, I'd like to point out that the devs working on OI are contributing their free time to do this. If you value OI then you're welcome to assist us and help get things updated faster. The stable release is about backporting critical security fixes, and this one sounds like the kind of thing we should look at backporting. So we will look into it and see what can be done. But it probably won't involve a version bump, more a patch to the older version. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On 15 Apr 2012, at 18:59, Martin Walter wrote: Would it be not easier and better to just make the newest version available? E.g. I would much more prefer just a samba-3.6.4 package than an updated samba-3.5.5. Yes, if we were on the new build system. So updating samba for /experimental wouldn't be too hard. But samba for oi_151a is stuck in an old build system, so updating it would require more effort than anyone we have is willing to take on. And as Rich pointed out, isn't really what the stable branch is about. If you have time you could have a look to see if there is a patch that applies against samba-3.5.5 that fixes the CVE. The usual place to look is other distro's patch sets against samba where their version is close to ours. *That* would be genuinely helpful and more use to us than building stuff :-) Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
Hi Martin, We've obtained the Debian security patches for 3.5.6 which should hopefully apply fairly cleanly against our 3.5.5: http://security-tracker.debian.org/tracker/source-package/samba We're looking into things. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] New BE every package update?
Hi, is it expected with the latest prestable that new backup BE is created even if minor binary is updated? $ pfexec pkg install scantailor Packages to update: 1 Create boot environment: Ne Create backup boot environment: Ano [...] $ pkg contents scantailor PATH usr usr/bin usr/bin/scantailor usr/bin/scantailor-cli usr/share usr/share/scantailor usr/share/scantailor/translations usr/share/scantailor/translations/scantailor_bg.qm usr/share/scantailor/translations/scantailor_cs.qm usr/share/scantailor/translations/scantailor_de.qm usr/share/scantailor/translations/scantailor_es.qm usr/share/scantailor/translations/scantailor_fr.qm usr/share/scantailor/translations/scantailor_it.qm usr/share/scantailor/translations/scantailor_ja.qm usr/share/scantailor/translations/scantailor_pl.qm usr/share/scantailor/translations/scantailor_pt_BR.qm usr/share/scantailor/translations/scantailor_ru.qm usr/share/scantailor/translations/scantailor_sk.qm usr/share/scantailor/translations/scantailor_uk.qm usr/share/scantailor/translations/scantailor_zh_TW.qm $ beadm list BE Active Mountpoint Space Policy Created libhal - - 5,23G static 2012-03-27 20:46 nscd - - 675M static 2012-04-11 21:35 oi-install - - 18,0M static 2011-10-03 23:44 openindiana- - 18,9M static 2011-10-07 19:07 openindiana-5 - - 3,19G static 2012-02-17 20:51 openindiana-6 - - 29,0M static 2012-02-17 23:05 openindiana-7 NR / 29,4G static 2012-04-12 21:42 openindiana-7-backup-1 - - 6,32M static 2012-04-13 22:25 openindiana-7-backup-2 - - 220K static 2012-04-15 18:05 openindiana-7-backup-3 - - 215K static 2012-04-15 21:13 openindiana-7-backup-4 - - 225K static 2012-04-15 21:46 I was expecting BE snapshots through ZFS snapshots as it was. Not new BE. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
Milan Jurik wrote: Hi, is it expected with the latest prestable that new backup BE is created even if minor binary is updated? Milan, That's how it works in Solaris 11, certainly. If the update will be straight into the running system, then the new BE is a snapshot before the update is applied. If the update will be into a new boot environment (requiring a reboot to activate), then the backup is the current boot environment which is unchanged by the update. Either way, you get a 'before' and an 'after' BE. I was expecting BE snapshots through ZFS snapshots as it was. Not new BE. How would you boot back to a ZFS snapshot if your update trashed the current BE? That's exactly what a BE is for (and it's little more than a ZFS snapshot anyway). -- Andrew ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
It is a kind of intimation on stability and usability of IPS and userland *trollface* 15.04.2012 23:51, Milan Jurik пишет: Hi, is it expected with the latest prestable that new backup BE is created even if minor binary is updated? $ pfexec pkg install scantailor Packages to update: 1 Create boot environment: Ne Create backup boot environment: Ano [...] $ pkg contents scantailor PATH usr usr/bin usr/bin/scantailor usr/bin/scantailor-cli usr/share usr/share/scantailor usr/share/scantailor/translations usr/share/scantailor/translations/scantailor_bg.qm usr/share/scantailor/translations/scantailor_cs.qm usr/share/scantailor/translations/scantailor_de.qm usr/share/scantailor/translations/scantailor_es.qm usr/share/scantailor/translations/scantailor_fr.qm usr/share/scantailor/translations/scantailor_it.qm usr/share/scantailor/translations/scantailor_ja.qm usr/share/scantailor/translations/scantailor_pl.qm usr/share/scantailor/translations/scantailor_pt_BR.qm usr/share/scantailor/translations/scantailor_ru.qm usr/share/scantailor/translations/scantailor_sk.qm usr/share/scantailor/translations/scantailor_uk.qm usr/share/scantailor/translations/scantailor_zh_TW.qm $ beadm list BE Active Mountpoint Space Policy Created libhal - - 5,23G static 2012-03-27 20:46 nscd - - 675M static 2012-04-11 21:35 oi-install - - 18,0M static 2011-10-03 23:44 openindiana- - 18,9M static 2011-10-07 19:07 openindiana-5 - - 3,19G static 2012-02-17 20:51 openindiana-6 - - 29,0M static 2012-02-17 23:05 openindiana-7 NR / 29,4G static 2012-04-12 21:42 openindiana-7-backup-1 - - 6,32M static 2012-04-13 22:25 openindiana-7-backup-2 - - 220K static 2012-04-15 18:05 openindiana-7-backup-3 - - 215K static 2012-04-15 21:13 openindiana-7-backup-4 - - 225K static 2012-04-15 21:46 I was expecting BE snapshots through ZFS snapshots as it was. Not new BE. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
Hi Andrew, Andrew Gabriel píše v ne 15. 04. 2012 v 21:27 +0100: Milan Jurik wrote: Hi, is it expected with the latest prestable that new backup BE is created even if minor binary is updated? Milan, That's how it works in Solaris 11, certainly. If the update will be straight into the running system, then the new BE is a snapshot before the update is applied. If the update will be into a new boot environment (requiring a reboot to activate), then the backup is the current boot environment which is unchanged by the update. Either way, you get a 'before' and an 'after' BE. I was expecting BE snapshots through ZFS snapshots as it was. Not new BE. How would you boot back to a ZFS snapshot if your update trashed the current BE? That's exactly what a BE is for (and it's little more than a ZFS snapshot anyway). I remembered there were ZFS snapshosts taken earlier, so it was (at least theoretically) possible to revert to some ZFS snapshot manually and I lived with last builds of Solaris only shortly so I missed this change. Previously only core bits were installed to new BE, no backup BE were created. The reality is that I am flooded with several new BEs per day. My grub list is increasing frequently. OK, I have to live with it :-) Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
On 15 Apr 2012, at 21:50, Milan Jurik wrote: The reality is that I am flooded with several new BEs per day. My grub list is increasing frequently. OK, I have to live with it :-) There's also: pkg --no-backup-be :-D ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
On 04/15/12 01:50 PM, Milan Jurik wrote: The reality is that I am flooded with several new BEs per day. My grub list is increasing frequently. OK, I have to live with it :-) Or you could use the --no-backup-be flag to pkg or beadm destroy the ones you know you'll never go back to. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
