Re: [OmniOS-discuss] "pkg update" NOW for KVM security fixes!

[qutic development]

Hi Dan,

> "pkg update" is your friend for LTS (r151014) and Stable (r151016). 

will this fix be part of r151006 LTS as well?

- Stefan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New bloody (IPS only this time)

[Günther Alka]

Thanks
napp-it is working again with this sudo fix

Gea

Am 12.02.2016 um 23:22 schrieb Dan McDonald:

Based on illumos-omnios master commit cc70d5b, uname -v reports 
"omnios-cc70d5b".

And omnios-build master commit 45f0d7b.

New with this update:

- Case-sensitivity now in ZFS test suite.

- GLDv3 improvement (by OmniTI's own Dale Ghent) which should produce less 
confusing dladm(1M) output.

- SunSSH and sudo now honor the illumos-bug-6057 ways of doing things.  Please PLEASE 
look for other "last login" weirdness, but there shouldn't be any.  If there 
is, PLEASE report it to this list ASAP.

- Speaking of SSH, OpenSSH now includes the full wad of Joyent work (modulo 1-2 
small differences) to be more of a SunSSH replacement.  If you haven't tried 
OpenSSH because you needed something from SunSSH, PLEASE try it now.


There is no new release media for this update, but I did update all of the 
packages, so you'll need to create a new BE and reboot.

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


--

Guenther Alka, Dipl.-Ing. (FH)
Leiter des Rechenzentrums
head of computer center

Tel 07171 602 627
Fax 07171 69259
guenther.a...@hfg-gmuend.de
http://rz.hfg-gmuend.de

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Intel Skylake

[Dale Ghent]

> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen  wrote:
> 
> Hi all,
> 
> Does Omnios 151014 support intel skylake?

The CPU itself, yes. However the series 100/C230 chipset's integrated i219 
ethernet isn't likely to be picked up by the igb driver.

/dale


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Zones Backup

[Bob Friesenhahn]

My microserver project (Xeon D based) is almost completely done now. 
All services are partitioned into zones.  I created a base zone and 
then cloned that zone to create the other zones.  All 'data' used by 
a zone is external via lofs mounts with only configuration and 
services being in the zone.


While there is already backup of the 'data' using my existing methods 
(zfs send to live fs on another system + rsync from a different 
system), I have not yet come up with the best way to back up zones.


It is very easy to back up zones as long as one is willing to 
replicate all the data in the zone.  Plenty of documentation exists 
for how to do this.  Since OmniOS uses "big" zones, this results in 
excessive redundant data (e.g. OmniOS distribution files) being backed 
up.  Backing up unneeded files wastes space and makes restoration more 
complicated.


Effort to restore a whole system from scratch needs to be minimized.

using GNU diff I can do something like:

  diff -r -q /zones/base/root /zones/web/root

and see differences between my base zone and a 'web' zone.  Most 
differences are due to spurious differences in OmniOS itself.  If 
there was a manifest available for the whole installed system (perhaps 
possible to derive from IPS), then it could be used to determine the 
files to ignore, and the files changed or added outside of OmniOS. 
This could be used to drive a backup system which only emits added or 
changed files from the base.


Does anyone have an effective zone backup method they can share which 
strips out all the cruft and retains only key files such as 
configuration files?


Thanks,

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Zones Backup

[Michael Mounteney]

On Sat, 13 Feb 2016 19:51:32 -0600 (CST)
Bob Friesenhahn  wrote:

> Does anyone have an effective zone backup method they can share which 
> strips out all the cruft and retains only key files such as 
> configuration files?

I'll put this on the table in case it fits:  I have a master
installation script which starts with a fresh installation and performs
all my customisation including installing and configuring zones.  I
don't back up the zones themselves;  just the reconfiguration
information.

It's almost automatic;  the only part that requires manual intervention
is running 'passwd' within a zone, since that requires console access
and won't accept redirected input from a file.  In due course I'll go
to LDAP and that problem with disappear.

In practice I don't have the nerve to run the entire script from start
to finish but tend to chop it up and run bits;  nevertheless it is
complete.

I use type=zfs for mounting zone data like /var/postgres and Dovecot's
IMAP store.  Each of those data-sets have set mountpoint=legacy and
cannot be viewed in the global zone.  They are 'important' of course,
and backed-up.

The long-running part of my script is a loop which starts:

# for ZONE in person diener KVM DHCP ; do ...

which creates and installs the zones.

To run a configuration script in a zone:

# cp -pr /support/omnios/zone/somezone/setupaservice /zone/somezone/root/tmp/
# zlogin somezone /tmp/setupaservice
# rm /zone/somezone/root/tmp/

and pkg -R to install packages into zones.

This does require the discipline to record your changes in your setup
script, but the benefit is that your zones are entirely recreatable and
don't have to be backed-up.

It seems long-winded but I reckon it's a lot quicker and tidier to apply
a customisation script to a fresh installation than it is to splice-in
stuff from /etc etc. from a back-up.

If you go for this, you will probably have to set up a parallel set of
zones as you develop your customisation script, to compare new with old
until your script is complete.

The above serves to preserve state for a planned upgrade as well.  The
only 'extras' FOR ME in that case are:

# pg_dumpall to prepare for a Postgres upgrade.
# slapcat to prepare for an OpenLDAP upgrade.

Hopefully the above gives you enough information to do it for yourself.

__
Michael Mounteney
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss