[OmniOS-discuss] omnios zone experiences on openindiana
Hi, I do not remember, where I discussed about this topic earlier, but I just wanted to tell a success-story: I had a "playground" omnios-blody (151013) in a VirtualBox. I upgraded it to the current 151014 LTS. Then I created a zone into it to have a template. Then I migrated this zone to my home nas, which run OpenIndiana 151a9. Everything succeed, but I had some slap on my face to learn things:) So, I thought I share those experiences: At First time I forget to detach the zone. Docs says, you do not have to. But you suck much more if you don't so, detach the zone! ;-) Usual google findings about this topic is original sun/oracle docs, where zfs send has a -rc options. I used -R option. I did not have a sunsol11 playground in the near. And at the attach phase. You will suck! But, one thing which may help: http://everycity.co.uk/alasdair/2011/10/fixing-no-active-dataset-on-zone-attach/ That script helps you to setting zfs property after the migration. After running that script you can mount the ROOT/zbe by hand, as Alisdair writes, and the attach... almost work. I made a mistake, tried the attach with -u, which also exists on oracle/sun docs, but not on the illumos branch, so my openindiana added their own publishers to my zone. So, I attached again, but now with the -n option, which eliminates the checkings. Then I could boot the zone. I fixed the publishers. Then I could clone the zone, so now I can have omnios 151014 lts zones on my openindiana nas. (And I could eliminate also eliminate one virtualbox linux machine, since a native illumos based system is much-much efficient and using fstype=lofs instead of nfs, and an os-level virtualization instead of machine virtualization, etc.) Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] A warning for upgraders with large numbers of BEs
Hi, "Dan McDonald" wrote at 2015-03-23 16:14: > Soon r151014 will be hitting the streets. WHEN THAT DOES, I have to warn > people, especially those jumping from r151006 to r151014 about a known issue > in grub. > > The illumos grub has serious memory management issues. It cannot cope with > too many boot environment (BE) entries. Sorry for semi-offtopicing the thread, but: Will the lx brand be restored in the upcoming release? Is there a feature map / release plan / anything available? I tried to find information regarding this topic without success. I checked this url: http://omnios.omniti.com/roadmap.php But nothing relevant information was there. It seems outdated / unmaintained. I've just recently find this distro. I used openindiana since Oracle... -- Did what they did to opensolaris -- So, I'm new here, sorry for lame questions. Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] slow ssh login, maybee to many locales?
Hi,
I faced with that, the login onto my new omnios zone is slow.
I tried to debug.
Many of the symptoms seemed pretty the same as this:
http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/
Also in my case it stopped at the same point: after the kexinit sent.
However, on my omnios, the cryptadm list showed this:
pasztor@omni:~$ cryptoadm list
User-level providers:
Provider: /usr/lib/security/$ISA/pkcs11_kernel.so
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Kernel software providers:
des
aes
arcfour
blowfish
ecc
sha1
sha2
md4
md5
rsa
swrand
Kernel hardware providers:
[---end of output]
So, in my case it did not contained the tpm module.
I tried the opposite: enabling the tpm module, but nothing changed.
(Maybe it become even slower. I did not count the seconds)
So, I rewert it back, and run the same truss command, which revealed this:
There are tons's of file openings in the /usr/lib/locale dir at that point:
24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0
24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA",
O_RDONLY) = 7
24560: 8.8236 fstat(7, 0x08047658)= 0
24560: 8.8237 mmap(0x, 94904, PROT_READ, MAP_PRIVATE, 7, 0) =
0xFEDE7000
24560: 8.8238 close(7)= 0
...
24560: 14.5883
open("/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA", O_RDONLY) = 7
24560: 14.5884 fstat(7, 0x08047678)= 0
24560: 14.6061 read(7, " ^ ( ( [EDCD ] ( [E1C1 ]".., 82) = 82
24560: 14.6063 close(7)= 0
24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0
24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE)Err#22 EINVAL
24560: 14.6069 fstat64(1, 0x08046E00) = 0
24560: 14.6070 brk(0x080689D0) = 0
24560: 14.6071 brk(0x0806A9D0) = 0
24560: 14.6072 fstat64(1, 0x08046D00) = 0
24560: 14.6074 close(5)= 0
24560: 14.6075 write(1, " C\n P O S I X\n a f _ Z".., 2891)= 2891
24556: 14.6076 read(3, " C\n P O S I X\n a f _ Z".., 5120) = 2891
24560: 14.6077 _exit(0)
24556: 14.6080 brk(0x080D0488) = 0
24556: 14.6082 brk(0x080D2488) = 0
24556: 14.6083 read(3, 0x080CD544, 5120) = 0
24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 ESPIPE
24556: 14.6085 close(3)= 0
24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0
So, does somebody knows what is happening at that point,
why,
and how can I "fine-tune" it?
Kind regards,
György Pásztor
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] omnios zone experiences on openindiana
Hi, "Volker A. Brandt" írta 2015-04-21 09:39-kor: > > I do not remember, where I discussed about this topic earlier, but I > > just wanted to tell a success-story: > > Thank you, interesting story. :-) > > > now I > > can have omnios 151014 lts zones on my openindiana nas. > > I am surprised that it works. What "brand" setting do you use for > the zone? My guess is "ipkg". Yes. It was ipkg on the source omnios too, so I just did not change that. I exported the config on omni, and imported here, and the zfs too. Maybe, if someone interested, I can try to reproduce the whole thing, and write a more "structured" howto / wikipage about it. Or try to write the whole into a shellscript and make the whole zone migration automated, and upload that to my github repo. (Not on this week! ;-) ) The only hard question for myself (poetic question) how to automate the root privilege gathering on the target side? (sudo, pfexec, su - ?) Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] slow ssh login, maybee to many locales?
Hi,
"Zach Malone" írta 2015-04-20 10:29-kor:
> Alternatively, you can define reverse entries for your SSH clients (if
> you control the DNS server), or just disable reverse DNS lookup in
> your sshd config altogether. Are SSH logins to localhost slow?
> 127.0.0.1 should be defined, so if ssh-ing from your host to itself is
> quick, that would indicate a DNS issue.
Maybe I did not wrote some detail, which I thought obvious for me.
Yes, ssh to localhost is sloow too.
It is my home network, and also I have proper dns records forward and in
reverse direction.
As I already said: when I log in from the same workstation to my
openindiana box or into an openindiana zoen, the ssh is subsecond fast!
The issue comes only, when I log in to my omnios zone.
> On Mon, Apr 20, 2015 at 10:17 AM, Schweiss, Chip wrote:
> >> I faced with that, the login onto my new omnios zone is slow.
> >> I tried to debug.
> >> Many of the symptoms seemed pretty the same as this:
> >>
> >> http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/
Please read this link first!
As I already wrote: I checked the "basic" things first.
Also I ruled out that case, what Jason writes about:
It is not the tpm module.
However the simptoms are similar: My ssh client is also wait at the same
phase: after the kexinit was sent.
(However, it not minutes in my case, only ~10 secs)
> >> There are tons's of file openings in the /usr/lib/locale dir at that
> >> point:
> >>
> >> 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0
> >> 24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA",
I don't know what happens at this point on server side, or what it tries to
read / check in locale settings, or why...
BUT
On one of my openindiana box:
pasztor@sb:~$ ls -l /usr/lib/locale/
total 14
drwxr-xr-x 8 root bin 8 Mar 5 2014 C
lrwxrwxrwx 1 root root 3 Mar 5 2014 POSIX -> ./C
And compare that to omnios:
pasztor@omni:~$ ls -l /usr/lib/locale/
total 2984
drwxr-xr-x 8 root bin 8 ápr. 18 14:00 af_ZA.UTF-8
...
drwxr-xr-x 8 root bin 8 ápr. 18 14:00 zh_SG.UTF-8
drwxr-xr-x 8 root bin 8 ápr. 18 14:00 zh_TW.UTF-8
pasztor@omni:~$ ls -l /usr/lib/locale/ |wc -l
223
And another difference:
pasztor@sb:~$ locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
vs.
pasztor@omni:~$ locale
LANG=hu_HU.UTF-8
LC_CTYPE="hu_HU.UTF-8"
LC_NUMERIC="hu_HU.UTF-8"
LC_TIME="hu_HU.UTF-8"
LC_COLLATE="hu_HU.UTF-8"
LC_MONETARY="hu_HU.UTF-8"
LC_MESSAGES="hu_HU.UTF-8"
LC_ALL=
So, Now I tried this:
root@omni:/usr/lib/locale# mkdir _
root@omni:/usr/lib/locale# mv * _ ; ln -s _/{C,POSIX} .
mv: cannot move ?_? to a subdirectory of itself, ?_/_?
root@omni:/usr/lib/locale# ls -l
total 15
lrwxrwxrwx 1 root root 3 Apr 21 23:18 C -> _/C
lrwxrwxrwx 1 root root 7 Apr 21 23:18 POSIX -> _/POSIX
drwxr-xr-x 223 root root 224 Apr 21 23:18 _
pasztor@intrepid:/tmp$ time ssh omni date
Tue Apr 21 23:19:02 UTC 2015
real0m0.248s
user0m0.004s
sys 0m0.008s
So, the problem is definitely about the locales.
Sshd check into every locale dir on the kexinit phase.
I think it's a bug. Why on earth does this needed to an ssh login?
Proof 2:
Now I revert back locale dir into it's original state:
root@omni:/usr/lib/locale# rm C POSIX ; mv _/* .
root@omni:/usr/lib/locale# rmdir _
Aaaand:
pasztor@intrepid:/tmp$ time ssh omni date
2015. április 21. 23:21:18 UTC
real0m9.575s
user0m0.028s
sys 0m0.004s
So, do you understand it now?
It is definitely not dns.
I quoted the output of truss on purpose, not just some L'art pour Lart
thing.
I also choose the subject carefully, not just because I was bored ;-)
The situation changed now, it's not "maybe" now. We have definitely a
proof about that.
Kind regards,
György Pásztor
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] slow ssh login, maybee to many locales?
Hi, "Andreas Luka" írta 2015-04-22 23:59-kor: > You maybe check your passing of the language environment from ssh-client > and sshd-server. I checked. > If you want to pass the language environment than make sure that I don't want. But it does automatically, so I just don't mind it :) > /etc/ssh/ssh_config in the client includes the line > SendEnv LANG LC_* Yes. It's in there in my ubuntu client's default config. > and that /etc/ssh/sshd_config in the server includes the line > AcceptEnv LANG LC_* OmniOS doesn't use openssh, they use their modified Solaris-derived version. It doesn't contain the AcceptEnv option. However, the manual says some exceptions, what are the defaultly accepted environment variables, and the manuel explicitly mentions these variables. But the login is still slow, if I write the "PermitUserEnvironment yes" into my ssd_config on OmniOS. > and that you have the same hungarian language files present on server and > client side.üDAndreas And with/without it: as my example showed: If I did not move away the language dirs from /usr/lib/locale then it can transfer my localized settings, and display the date in hungarian. So it works fine. The problem is still that, it's slow, because look into all locale dir... Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Extending the installer
Hi, "Michael Rasmussen" írta 2016-02-26 20:40-kor: > I have thought about this for some time. I think it is silly that users > are not guided through the process of the initial setup of network and > this is also the biggest barrier for new users (IMHO). To fix this I > would suggest that the installer is extended with a GUI for doing just > this. I could be implemented in one of two ways: > > 1) Extend the current installer > 2) Start a GUI after first boot provided that the system contains known > nics (Ethernet). I am not against improving the system. But this is a server distro. If setting up the network following the docs is a barrier: Then the next step will be a barrier than. Than the next. Than the next, etc. 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?! What is your opinion about this? Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] theoretical question: oi151a9->omni151014
Hi, It is a theoretical question, what I will write, but I would like to know answers and thoughts about it, since I will try that in practice soon: I have an OpenIndiana 151a9 on my home nas. Most of the services are run from zones. There are only one (or few) thing(s), which run from the GZ: nis-master, and nfs/samba shares. (Sharings are handled through the appropriate zfs attributes, there is nothing extra around that.) There is a (nis-)slave is in one of the zones. Most of the zones are "typical" (if that word exists at all in this context :D) openindiana zones too with the same 151a9 version. Exceptions: One of the zones run virtualbox VMs. (Currently only one, but previously, I had two, and later, maybe I will use more then that.) One of the zones run omnios: pasztor@omni:~$ pkg info entire |grep FMRI FMRI: pkg://omnios/entire@11-0.151014:20150402T192159Z In one of the zones, I run a pkgrepo, I tried to build packages based on sfe specfiles, which was not exactly there, when I started to use my nas. eg. smartmontools. Then I added this repo to my gz. One extra thing about this home-nas: the rpool is on a 64G pendrive now. The zones, and my important data is on the spinning disks. (The name of that pool is tank. :D) I would like to use OmniOS on the host system instead. I had many reasons for why I would like that. In theory I have two idea how to implement this "upgrade": Idea #1: * stop all the zones. * export zone configurations, and save them onto a dataset on tank * Make snapshot about all the important zfs datasets in rpool, * then make a backup copy to tank using send&receive. * Plug out the pendrive * Plug in an empty new pendrive, and install omnios onto it * import zone configurations * attach the zones * start the zones * fix non-working things, eg.: recreate or reorganize my nis service * be happy! If something fails, I have a fallback: plug back the original pendrive Idea #2: * plug in the new & empty pendrive into the system * follow this guide to mirror the rpool: http://wiki.openindiana.org/oi/2.1+Post-installation * test the system if one of the pendrives is enough * plug out one of the pendrives, and consider it as a fallback * try some magic with pkg publishers /* magic happens here !!! */ * try to upgrade entire to omnios's 151014 /* and here :D */ * handle / fix the unexpected gotchas /* maybe here too :) */ * be happy! If something fails, I can have two fallback: * the pendrive, which I removed * the previous BE, which contains my last working OI system :) If I am honest, then I like idea#2 much more. It may contain adventures, but would be a really nice way if it'd work. It was also an adventure, when oracle stoped opensolaris, or at least things around that. But we wanted to upgrade our production storage server at my previous workplace from build143 to openindiana 151a, and we had to manually handle some package dependencies, etc. and that was not even well tested or well documented on openindiana's wiki to, how to do that, but at least, it was a good starting point. I think, this situation is a bit similar to that old story :) Does sy. has some good advice, best practice, mathematical proof about that it will never ever work, etc? One though that come into my mind: Try the whole situation (idea#2) first in a virtualbox machine, to see at least if this kind of upgrade could work. Not with this kind of complexity, just a freshly installed oi151a8 upgrade to a9, than to omni151014. (I have not done this yet, but I think, this will be the 0th step.) Did anybody tried this ever? Kind regards, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] [FWD] Re: Routing challlenges
Hi, sorry, I forget to modify the "to", to the list.. - Forwarded message from PÁSZTOR György - Date: Thu, 7 Apr 2016 21:36:55 +0200 From: PÁSZTOR György To: "Schweiss, Chip" Hi, "Schweiss, Chip" írta 2016-04-07 10:52-kor: > The problem I am having is that when on privileged machine on one of the > vlans also on the service side that has access to the management SSH port > the TCP SYN comes in the management VLAN but the SYNACK goes out the > service VLAN instead of routing back out its connecting port. This causes > a split route and the firewall blocks the connection because the connection > never appears complete. > > Traffic is flowing like this: > client firewall omnnios > 10.28.0.106 -> 10.28.0.254->10.28.125.254 -> 10.28.125.44 > > 10.28.0.106 <- 10.28.0.44 > > How can I cause connections to only communicate on the vlan that the > connection is initiated from? The problem pretty much sounds, ... to that, where the solution would be this, if it were a linux: http://lartc.org/howto/lartc.rpdb.multiple-links.html I do not know, if there is similar solution in illumos based systems. I mean: Policy based routing. If there, then, that is the solution. Other possible working solution: As far as I understood the requirements, you want to serve nfs, and other things on one 10ge interface, but let in ssh only on another subnet on a 1ge interface. Solution a; * create a "stub network", which is only available on the host, and zones, * create a zone for ssh (let's call it jumpzone): which access the 1ge port and the stub network, * put the hosts sshd to listen only on localhost, and on the stub network interface Solution b; * do not configure 10ge interface on the "host" * create a "service" zone, which exclusively accesses the 10ge interface. * "service" zone would be only configured to access 10.28.0 At solution b: as far as I know, newer illumos kernels supports to export nfs and smbfs from zones, so it may work. But it may contain other gotchas which we may not foreseen. Or,... find docs about policy based routing on illumos. Cheers, Gyu - End forwarded message - ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Introducing io-lx -- an attempt to port LX Zones to OmniOS
Hi, "Dan McDonald" írta 2016-03-07 21:47-kor: > After I'm comfortable with no ipkg/lipkg regressions, I will need to spend > some design time figuring out how LX zones will look on OmniOS. I will not > be porting vmadm(1M) over from SmartOS, so I need to think about how LX will > fit in with traditional zone tools. I may discover other problems, but until > I start the '018 process, and immediately after '018 ships, I will need to > ensure no ipkg/lipkg regressions first and foremost. > > It's not much, but it's a start. Is there any news about this io-lx project? Will that get into 018? Can I test it somewhere already? eg. in a fresh 017? Or should I ONU to oi-lx? Is there a howto online how should I do that? Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX for OmniOS update
Hi Dan, "Stephan Budach" írta 2016-08-09 15:00-kor: > I'd love to be able to actually spend any time on this, but my workload > doesn't allow it??? I hope to get into this at the end of september. > Don't give up on it, please??? ;) +1 The same case here. I tried it the first time, you mentioned this on the list. Al-something worked. Then I had no more time to deal with that. I changed country a month ago. Most of my stuff is still at my "from" country. I have now only my old laptop from '11, with an ubuntu 12.04, so I could try your improvements on that, in a virtualbox. My omnios nas is still at the "from" country, so I do not even have space for backup data from my laptop, (and wipe that old over-hacked ubuntu, so finally I could replace it with a more recent something.) So, please keep up the good work! As soon as the things calm down around me, I plan to test, even contribute my ideas around the installation of an lx zones. eg.: one of my ideas was, to improve the zone installer part, and instead of wrapping out prepared zfs dataset tin, we can use some more generic, like debootstrapping debian-ish (eg.: ubuntu) systems. There is also a debootstrap-like tool for rpm-based systems, but I do not remember the name of it from the top of my head. At least, my opinion is that, if we create an installation method onec than it needs minimal maintenance later for supporting newer debian/ubuntu versions. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151020 is now out!
Hi, "Dan McDonald" írta 2016-11-04 11:26-kor: > NOTE that we froze r151020 prior to the BSD Loader push in illumos-gate. We > did so to not delay this release. This does mean that the next release, > r151022, which is also the next LTS, will be late, and may have other > substantial changes. How big will be that change? Can grub still work in 151022, or only the BSD Loader will be supported from that point? Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Install onto usb stick
Hi, I barely remember, if it was a topic here, or on the openindiana-discuss list, if there are some best practice to install omnios/openindiana/illumos* onto a pendrive. My current home nas is installed onto a pendrive. But my previous pendrive died after 1 or 2 years, so I had to reinstall it lately. Since in the last couple of month my nas was turned off, due to other reasons, it just came into my mind, that I should ask that here, if sy has any good advice on that. As I said, it's working now, I just want to prevent the next pendrive damage. The "practice": the base system is on the pendrive, but the most of the services runs in zones. So when my first pendrive died, practically I just had to import my pool from the spinning disks, and create the zone configurations again, based on the prevoius exports. The zones are on the spinning disks. So, the config: rpool: pendrive tank: raidz from spinning disks, and I have a samsung 840 evo, what is partitioned into 2 half, the first partition is smaller, that is the zil for "tank", the second partition is around half of the ssd, and that is the l2arc for "tank". Any advice, to make it better / prevent pendrive / ssd failures? Thanks, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
Hi, "Michael Rasmussen" írta 2017-01-05 19:44-kor: > On Thu, 5 Jan 2017 13:34:40 -0500 > Dan McDonald wrote: > > > I notice you're running on vmxnet... I wonder if your host is preventing > > you from creating vNICs through some sort of address filtering? > > > Does it not require promiscuous mode to be able to create a nic alias? > I do not think this is supported with default settings in VmWare. In my home nas, I bumped into a similar problem. - Host is omnios 151014. -- There is a zone, named vbox. --- There is a linux virtual machine inside that, which access the local network as it should, interface: eth0, br0(lxcname.eth0) There is a lxc container in that virtual machine The lxc container didn't had access to the network, since virtualbox+ vnic filtered out frames, didn't belong to it's address, so from the global zone's perspective, the linux machine's vnic shouldn't get the frames where it's destination was the lxc's mac. So, I set up a proxy arp in the linux virtual machine: $ cat /etc/sysctl.d/lxc-net-dep.conf net.ipv4.ip_forward=1 net.ipv4.conf.br0.proxy_arp=1 net.ipv4.conf.eth0.proxy_arp=1 Also, for safety, inside the /etc/network/interfaces, there is an up command entry for the iface br0 inet static: up route add -host 172.28.33.40 dev br0 up sysctl net.ipv4.conf.br0.proxy_arp=1 down route del -host 172.28.33.40 So for eth0, there is a regular eth0 inet static entry, and there is this br0, with the same ip, as eth0, but it adds a p2p route entry to the routing table at bringing up. Since, br0 doesn't exist at host boot up time, the net.ipv4.conf.br0.proxy_arp=1 is practically useless in the sysctl.d.conf The 172.28.33.40 is the address of the lxc, while my whole home network is the 172.28.33.0/24. Outside from my omni nas, the linux vm, and the lxc seems like the same mac: # arp -n | grep -E '36|40' 172.28.33.36 ether 02:08:20:0d:ae:ea C wlan0 172.28.33.40 ether 02:08:20:0d:ae:ea C wlan0 I don't know, if it's possible on illumos but proxy arp can be a solution. Not a nice one, but a sulution! ;-) Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts
Hi, "Mini Trader" írta 2017-01-10 18:49-kor: > Currently the UID Mapping between the host (OmniOS) and my zone (Linux) is > based purely on UID. Obviously the UID's on my Linux zone are going to be > very different from my OmniOS setup. > > Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup for > unrecognized users and groups or mapping from a numerical id to user? I think, the power of lofs, that it doesn't do translations, etc. like nfs does. This behaviour doesn't depend on if the zone is an lx zone, or a solarish one. If you have a dataset what you want to use in multiple zones at the same time, then it's your responsibility to keep the same uid set in all of them. And that's also not an impossible thing: you can use yp or ldap for this purpose. Whatever is your favourite. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] omnios vs xen experiences
Hi, Recently I started to build a new home nas, and I thought it would be a good idea to use xen on the bare metal. On my previous nas (Microserver Gen7 with amd's NL54 cpu -> no kvm) I used virtualbox, to run VMs. My new motherboard is a supermicro with integrated intel cards supporting pci sr-iov and other fancy stuff. I looked around, and alpine linux (3.6.2) seemed a good choice for dom0 os: small, can run from ramdisk (os can be on a pendrive), etc. and they have a really fresh xen. That's where the problems started. Following old google hits and my old memories, I was able to install omnios in both pv and hvm mode into a vm. The only thing what didn't really worked: networking. igbevf and ixgbevf drivers seems missing from illumos. xnf driver just crashed. First I thought it's xnf's problem, so I tried older omnios, latest openindiana build, etc. if it worked somewhere, but it always crashed. Then I tried to find out which xen version brought in a change which broke illumos's xnf driver, so I tried alpine 2.6, 3.0 -> xnf worked. alpine 3.3 didn't even boot. (maybe didn't like supermicro's virtual cd emulation) alpine 3.4 with xen 4.6 -> fail alpine 3.2 with xen 4.5.1 -> still works. So something happened with xen's interface between 4.5.1 and 4.6 which makes illumos's xnf driver crashing. If I can get some mentorship from one of the omniosce developers, I'd be glad if I can fix the problem in illumos. Would someone help me on this? Now plan to put some local disk into the new nas (that's the only part, what I don't have yet :D) and setup a build environment. I saw, that there is a complete wiki article about that in the omniti wiki. It's not urgent for me to "upgrade" to the new nas. It's completely fine for me if it won't go into "production" for a couple of months. Btw.: I tried to directly assign a complete (not a vf) card, and that worked with the ixgbe driver perfectly. Another foggy part: https://wiki.xenproject.org/wiki/Storage_driver_domains Here the doc write it works with FreeBSD oob. It seems, it's also problematic with OmniOS. I tried that with the 3.6.2 alpine which has xen 4.8.1 Regards, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Omios, hvm and AWS
Hi, "Al Slater" írta 2017-07-27 12:17-kor: > So, I thought I would try to produce my own AMI with hvm virtualization. > > I am looking to use omniosce r151022, is this likely to work at all? I haven't tryed to upgrade my r151022 with the ce updates, but I'm pretty sure that it must work. > I have read https://omnios.omniti.com/wiki.php/Ec2Ami, does anyone know > how that procedure would be amended to cater for loader/hvm instead of > pv-grub? If you use hvm, then there is no need for an extra loader. Just install omnios, as you would onto the "virtual" hdd. However, I never tried amazon's env. I experimenting with omnios on my home nas. (See my mail two days ago) The only drawback what I found: if the xen hypervisor is >=4.6 (or >4.5.1 I don't know yet), then the pv network driver won't work. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] initialboot
Hi, I hope you don't mind, but I started a new thread with this, since it seems a completly new topic. "Al Slater" írta 2017-07-31 21:05-kor: > One more question though, is there any way to enable an SMF service for > the next reboot, but not immediately. Specifically, I want to enable > the initial-boot service with a .initialboot file in place, then create > a new AMI. I don't completely understand. You want to enable initialboot after the boot was complete, and only after a certain amount of time? I'm not sure, what this initialboot exactly does, but it seems not a simple service, it's a milestone. Maybe, I would not mess with it. Otherwise, if I need a delay between the service and the boot, and it's important to remain "disabled" while it's not enabled: Create an @reboot cronjob. I don't remember which cron implementation is the default. On linux's vixie's cron the time can be @reboot. > I wist to use .initialboot to grab the instance configuration from > amazon (hostname, root keys etc) and configure appropriately when the > new instance starts. Again: I don't completely understand your scenario. You created one ami, and you want to "close it back", and clone it several times, so after it's first reboot, it should do the initalboot steps? Why do you want to wait? What I just found about the /.initialboot, it's a simple shell script. If you need to wait here, why not just put a sleep command into the beginning of the script? Or if you have to wait for some specific resource: Why don't poll it once per every 5 sec or so? Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] initialboot
Hi, "Al Slater" írta 2017-07-31 22:24-kor: > I was thinking that if there was some way to "re-enable" initial-boot, > then I could drop a /.initialboot script, re-enable initial-boot and > then shutdown before creating new AMI, such that when an instance based > upon the new AMI was launched, it would run .initialboot. > > The problem is, enabling initial-boot immediately runs the .initialboot > script and then disables itself. So, I hoped there was a way to enable > the service such that it did not immediately enable, but was enabled so > it would start after the next reboot. It's much cleaner now. I saw sg. in svcadm's man, about marking a service temporarily... which is in effect until the next reboot. But, a much simpler solution what I tested: I started my script with this: trap 'rm /tmp/x' SIGINT trap 'rm /tmp/x' SIGTERM while [ -f /tmp/x ]; do sleep 5 done And here follows your real script. Before you'd enable again initial-boot, just touch /tmp/x Maybe not the best workaround, but at least it works! ;) Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] ipkg zone update after global update
Hi, I've just followed the directions of the update procedure described here: https://omniosce.org/upgrade.html It seems, the update of the ipkg zones doesn't work that smooth, how the docs says. After the reboot, I tried to reattach the zone but without any success. I usually got this: root@nas-omni:~# zoneadm -z rt attach -u Log File: /var/tmp/rt.attach_log.ZqaOCf Attach Path: /zones/rt/root Attach ZFS Dataset: stash/zones/rt/ROOT/zbe-2 Installing: Using pre-existing data in zonepath Global zone version: entire@11-0.151026:20180504T112744Z Non-Global zone version: entire@11-0.151024:20171030T140754Z Cache: Using /var/pkg/publisher. Updating non-global zone: Output follows Creating Plan (Solver setup): -ERROR: Could not update attaching zone Result: Attach Failed. In the logfile, afther the same pre-task information, I can see this: PKG: install --accept --no-refresh entire@11-0.151026:20180504T112744Z pkg://omnios/system/library/gcc-5-runtime pkg://omnios/system/library/g++-5-runtime pkg://omnios/system/library/gcc-6-runtime pkg://omnios/system/library/g++-6-runtime pkg install: No matching version of entire can be installed: Reject: pkg://omnios/entire@11-0.151026 Reason: No version matching 'require' dependency SUNWcs@0.5.11-0.151026 can be installed Reject: pkg://omnios/SUNWcs@0.5.11-0.151026 Reason: This version is excluded by installed incorporation consolidation/osnet/osnet-incorporation@0.5.11-0.151024 ... I tried to force-attach it: root@nas-omni:~# zoneadm -z rt attach -F But, boot didn't succeeded: root@nas-omni:~# zoneadm -z rt boot zone 'rt': ERROR: Unable to mount the zone's ZFS dataset. zone 'rt': zoneadm: zone 'rt': call to zoneadmd failed So, to actually fix it, I needed to do the following: root@nas-omni:~# zfs mount stash/zones/rt/ROOT/zbe-2 It was weird, since it seems, the publisher was successfully updated, just the upgrade procedure didn't went that smooth somehow: root@nas-omni:~# pkg -R /zones/rt/root publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniosce.org/r151026/core/ niksula.hut.fi origin online F http://pkg.niksula.hut.fi/ extra.omniosorigin online F https://pkg.omniosce.org/r151026/extra/ root@nas-omni:~# pkg -R /zones/rt/root update Packages to remove: 8 Packages to install: 7 Packages to update: 396 Packages to change: 2 Mediators to change: 3 Services to change: 3 DOWNLOADPKGS FILESXFER (MB) SPEED Completed413/413 14808/14808 186.0/186.0 635k/s PHASE ITEMS Removing old actions 12646/12646 Installing new actions 9065/9065 Updating modified actions10734/10734 Updating package state database Done Updating package cache 404/404 Updating image stateDone Creating fast lookup database Done Updating package cache 3/3 --- Find release notes: https://omniosce.org/releasenotes --- Get a support contract:https://omniosce.org/invoice Sponsor OmniOS development:https://omniosce.org/patron Contribute to OmniOS: https://omniosce.org/joinus --- Now, at this point, let's try an detach&attach cycle: root@nas-omni:~# zoneadm -z rt detach root@nas-omni:~# zoneadm -z rt attach Log File: /var/tmp/rt.attach_log.SQa42g Attach Path: /zones/rt/root Attach ZFS Dataset: stash/zones/rt/ROOT/zbe-2 Installing: Using pre-existing data in zonepath Global zone version: entire@11-0.151026:20180504T112744Z Non-Global zone version: entire@11-0.151026:20180504T112744Z Cache: Using /var/pkg/publisher. Updating non-global zone: Output follows No updates necessary for this image. Result: Attach Succeeded. Step n-1: fingers crossed! Step n: root@nas-omni:~# zoneadm -z rt boot Step n+1, just because I'm paranoid / like to dobulecheck: pasztor@rt:~$ sudo pkg refresh pasztor@rt:~$ sudo pkg update No updates available for this image. Maybe, it could be useful to extend the upgrade instructions with some kind of extra hints, like this, how can someone fix the upgrade of an ipkg zone if that fails. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http:
[OmniOS-discuss] ami instance upgrade problems
Hi, I'm learning amazon, so I thought it would be nice, if I'd play with an omnios inside my free tier experiments instead of linux. I installed omnios from the "official" source: ami-0169c5108d1bdfd57 (Yes, I choose Ohio instead of N. Virginia to play at) One small sidenote: ipv6 is not enabled in the official image, however I configured so for the instance. After install I manually run this: ipadm create-addr -T addrconf xnf0/v6 Well, it solved everything. It seems way more simpleer then toying with linux. But... I can not update my instance. pkg update created the omnios-1 be, but I can not activate it. root@ip-172-31-28-110:~# beadm list BE Active Mountpoint Space Policy Created omnios NR / 801M static 2018-05-04 18:52 omnios-1 - /tmp/tmpTvggQP 158M static 2018-07-20 00:15 root@ip-172-31-28-110:~# beadm activate -v omnios-1 be_do_installboot: device c4t0d0 be_do_installboot: install failed for device c4t0d0. Command: "/usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c4t0d0s0" Errors: open: No such file or directory Unable to open device /dev/rdsk/c4t0d0s0 be_run_cmd: command terminated with error status: 1 Unable to activate omnios-1. Error installing boot files. root@ip-172-31-28-110:~# ls -l /dev/rdsk/*t0d0s0 lrwxrwxrwx 1 root root 34 Jul 18 22:07 /dev/rdsk/c1t0d0s0 -> ../../devices/xpvd/xdf@51712:a,raw lrwxrwxrwx 1 root root 8 Jul 20 00:21 /dev/rdsk/c4t0d0s0 -> c1t0d0s0 root@ip-172-31-28-110:~# /usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c1t0d0s0 bootblock version installed on /dev/rdsk/c1t0d0s0 is more recent or identical Use -F to override or install without the -u option root@ip-172-31-28-110:~# zpool status -v pool: syspool state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM syspool ONLINE 0 0 0 c4t0d0ONLINE 0 0 0 errors: No known data errors root@ip-172-31-28-110:~# echo | format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c1t0d0 /xpvd/xdf@51712 Specify disk (enter its number): Specify disk (enter its number): Well, I'm stucked at this point. I don't know how could I fix these. I assume, the problem is, somewhere around the c4 vs c1 numbering, so it try to open the wrong device. Note.: So let's just assume, it should work, without running the installboot command. root@ip-172-31-28-110:~# cd /usr/sbin root@ip-172-31-28-110:/usr/sbin# mv installboot installboot.save root@ip-172-31-28-110:/usr/sbin# ln -s ../bin/true installboot root@ip-172-31-28-110:/usr/sbin# beadm activate -v omnios-1 be_do_installboot: device c4t0d0 Command: "/usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c4t0d0s0" Activated successfully root@ip-172-31-28-110:/usr/sbin# reboot OmniOS 5.11 omnios-r151026-b6848f4455 June 2018 root@ip-172-31-28-110:~# beadm list BE Active Mountpoint Space Policy Created omnios - - 3.66M static 2018-05-04 18:52 omnios-1 NR / 1.01G static 2018-07-20 00:15 Will. It's a very dirty hack. Is there a nicer way to fix this c4 vs c1 thing? Btw.: it seems installboot would give back false, even if it could open the device, because it already has the same version of boot block. Shouldn't that circumstance checked on behalf of beadm? Cheers, gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ami instance upgrade problems
Hi, "Al Slater" írta 2018-07-25 10:08-kor: > The problem is caused, I think, by device numbering differences in xen > versus ec2. > > I solved this problem when creating my AMIs by the following procedure. > > 1. Create an extra volume in EC2 with the same size as the instance > boot volume. > > 2. Attach the extra volume to the instance. > > 3. zpool attach the extra volume (c1t1d0?) >zpool attach rpool c4t0d0 c1t1d0 > > 4. zpool detach the original volume with incorrect name (c4t0d0) >zpool detach rpool c4t0d0 > > 5. zpool attach the original volume with the proper name (c1t0d0) >zpool attach rpool c1t1d0 c0t0d0 > > 6. zpool detach the extra volume. >zpool detach rpool c1t1d0 > > 7. Detach the extra volume from the instance and delete it. > > Double check all disk names in your instances first! Nice trick tho! Checked, worked. I mean at least if I run a beadm activate omnios-1 it says Activated succesfully. And on omnios-1, the installboot is not diverted to true. -> I could clean up the garbage now, and destroy the old omnios be. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] beadm activate error
Hi, "Jürgen Bereuter" írta 2018-07-27 09:31-kor: > $ sudo beadm activate -v omnios-2 > > be_do_installboot: device c5t0d0 > be_do_installboot: install failed for device c5t0d0. > Command: "/usr/sbin/installboot -m -f /tmp/.be.BDaasb/boot/pmbr > /tmp/.be.BDaasb/boot/gptzfsboot /dev/rdsk/c5t0d0s1" > Errors: > open: No such file or directory > Unable to open device /dev/rdsk/c5t0d0s1 > be_run_cmd: command terminated with error status: 1 > Unable to activate omnios-2. > Error installing boot files. > > > Obviously, there is no device with dev/rdsk/c5* on my system. When i change > the device to the correct one, beadm says there are problems with opening or > reading the tmp directory. Although zpool says so: It's not a nice sulution, but until a better official sulition is published, you can do the same, what I've just described a couple of days ago regarding my ami instance upgrade problems. Regards, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] screnrc or terminfo/termcap definitions changed in 151026
Hi!
Can someone tell me, what changed in screenrc or termcap between 151022 and
151026?
When I pressed the usual ^a d to detach from my screen session, on the '22
it clears the screen before screen command would exit while on the '26 it
leaves garbage on my terminal.
Terminal type: xterm (linux, mate-terminal)
I don't even have an idea where to check for differences? The terminfo db,
or in /etc/screenrc?
If it helps, some comparation between '22 and '26:
[pasztor@nuc ~]$ diff -u <(ssh endor cat /etc/screenrc | grep -vE '^(#.*|)$' |
sort ) <(ssh iroh cat /etc/screenrc | grep -vE '^(#.*|)$' | sort )
--- /dev/fd/63 2018-09-11 17:30:58.174232095 +0200
+++ /dev/fd/62 2018-09-11 17:30:58.177565428 +0200
@@ -1,36 +1,31 @@
autodetach on
bind ^\
-bind .
-bind \\
-bind h
-bind ^h
-bind '}' history
-bind 'I' login on
-bind k
+bind } history
+bind I login on
bind ^k
-bind 'K' kill
-bind 'O' login off
-bind ^] paste [.]
+bind K kill
+bind O login off
+bind \\ quit
+deflogin on
defscrollback 1000
-pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."
-register ] "\033:se ai\015a"
-register [ "\033:se noai\015a"
startup_message off
-termcapinfo hp700
'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
-termcapinfo linux C8
-termcapinfo wy75-42 xo:hs@
-termcapinfo wy*
CS=\E[?1h:CE=\E[?1l:vi=\E[?25l:ve=\E[?25h:VR=\E[?5h:VN=\E[?5l:cb=\E[1K:CD=\E[1J
-termcapinfo xterm* be
-termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
-termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
-termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~'
-termcapinfo xterm* OL=100
-termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l'
-termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
-termcapinfo xterm 'XC=K%,%\E(B,[\304,\326,]\334,{\344,|\366,}\374,~\337'
-termcapinfo xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l
-termcap vt100* ms:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC
-termcap xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
-terminfo vt100*
ms:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC
-terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
+termcap facit al=\E[L\E[K:AL@:dl@:DL@:cs=\E[%i%d;%dr:ic@
+termcap facit|vt100|xterm LP:G0
+termcap hp700
'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
+termcap sun
'up=^K:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:IC=\E[%d@:WS=1000\E[8;%d;%dt'
+termcap vt100 dl=5\E[M
+termcap wy75-42 nx:xo:Z0=\E[?3h\E[31h:Z1=\E[?3l\E[31h
+termcap xterm|fptwist hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
+termcap xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
+termcap xterm|xterms|xs ti=\E7\E[?47l
+terminfo facit al=\E[L\E[K:AL@:dl@:DL@:cs=\E[%i%p1%d;%p2%dr:ic@
+terminfo facit|vt100|xterm LP:G0
+terminfo hp700
'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
+terminfo sun
'up=^K:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC:IC=\E[%p1%d@:WS=\E[8;%p1%d;%p2%dt$<1000>'
+terminfo vt100 dl=5\E[M
+terminfo wy75-42 nx:xo:Z0=\E[?3h\E[31h:Z1=\E[?3l\E[31h
+terminfo xterm|fptwist hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
+terminfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
+terminfo xterm|xterms|xs ti=\E7\E[?47l
+vbell_msg " Wuff Wuff!! "
vbell on
If it would not be clear: endor is the '22, and iroh is the '26.
I tried to add these to the end of my screenrc:
$ tail -15 /etc/screenrc
# ---
pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."
register ] "\033:se ai\015a"
register [ "\033:se noai\015a"
termcapinfo xterm* be
termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~'
termcapinfo xterm* OL=100
termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l'
termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
termcapinfo xterm 'XC=K%,%\E(B,[\304,\326,]\334,{\344,|\366,}\374,~\337'
termcapinfo xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l
termcap xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
But this also not helped to solve the problem.
Any ideas?
Regards,
Gyu
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] screnrc or terminfo/termcap definitions changed in 151026
Hi, "Andy Fiddaman" írta 2018-09-11 22:16-kor: > > On Tue, 11 Sep 2018, P?SZTOR Gy?rgy wrote: > ; Can someone tell me, what changed in screenrc or termcap between 151022 and > ; 151026? > > According to the release notes at https://omniosce.org/releasenotes > > o The /etc/screenrc file delivered by the screen package is now based on the > recommended global template as delivered by the authors; you may wish to > check > that it still meets your needs. If you have previously customised this file > then it will not be updated but the new template file will be installed as > /etc/screenrc.new. Ok, maybe It was not obvious from my e-mail: I used screen with default settings. No local change were made originally. > o screen is now linked against ncurses in order to support more terminal > types (e.g. iterm) This may explain why screen broke. At least the way it exits and cleans the screen. It still jumps back to the right upper corner, just leave the garbage on your terminal. Regards, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] dns howto
Hi,
Do someone have any best practice how to serve dns from omnios?
I'm migrating my home nas from my old N54L box to a custom built nas pc.
On the old box I have omnios 151014, where I served dns requests in my home
lan via an old zone migrated from the earlier openindiana 151a9 zone.
The 151a9 zone worked without any problem on the 151014 omnious without a
problem.
But I assume, some changes happened between 014 and 026 which broke binary
compatibility because neither my old 014 zone, neither my old 151a9 zone
was not able to start on the 026.
The 014 was not a big problem, even if there were no upgrade path.
I started with a clean zone, and moved there the other stuff (eg. nginx).
But the dns is kind a tricky. I checked how I served dns, and it seems
bind9 was part of the openindiana.org repo, while I was not able to find
any dns-related solution for current omnios releases.
I thought I'll do that with a debian9 lx zone.
Well, it's more or less work, but this error messages worries me in bind9's
log:
root@dns:/var/log/bind9# tail bind.log
22-Sep-2018 14:39:31.166 general: error:
../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:31.167 general: error: setsockopt(520, IP_RECVTOS) failed:
Protocol not available
22-Sep-2018 14:39:31.167 general: error:
../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:31.167 general: error: setsockopt(521, IP_RECVTOS) failed:
Protocol not available
22-Sep-2018 14:39:44.555 general: error:
../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.555 general: error: setsockopt(520, IP_RECVTOS) failed:
Protocol not available
22-Sep-2018 14:39:44.582 general: error:
../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.583 general: error: setsockopt(520, IP_RECVTOS) failed:
Protocol not available
22-Sep-2018 14:39:44.711 general: error:
../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.711 general: error: setsockopt(24, IP_RECVTOS) failed:
Protocol not available
relevant logging config:
root@dns:/etc/bind# grep -A 7 logging named.conf.options
logging {
channel b_log {
file "/var/log/bind9/bind.log" versions 30 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
Does anyone have any idea how to solve this?
I already added the -4 option to /etc/default/bind9.
I found this conversation regarding the topic:
https://echelog.com/logs/browse/smartos/1477605600
This is from 2 years ago, and doesn't seem helpful by now, since bind
starts, just it dumps an insane amount of log about this protocol
unavailable. My eyes are bleeding, I barely see what protocol is missing
here. As I wrote, I tried the obvious: adding -4 to the options, and I see
that amongs the running process's arguments.
Thanks for every help!
Regards,
Gyu
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] screnrc or terminfo/termcap definitions changed in 151026
Hi, "Andy Fiddaman" írta 2018-09-11 22:16-kor: > According to the release notes at https://omniosce.org/releasenotes Well, it's not a solution, but finally I "solved" the problem with a workaround: I started to learn tmux instead. It seams tmux works more flawless in 026. I added some entry to my .tmux.conf to make my most often used keys similar to the original screen behaviour: unbind C-b set-option -g prefix C-a bind-key C-a send-prefix bind ' ' next-window bind n next-layout bind BSpace previous-window Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] dns howto
Hi all, "Gary Gendel" írta 2018-09-23 15:20-kor: > Or use another option like "unbound" available from pkgsrc. I use a > split-horizon setup where requests from the internal network get local > NAT addresses so they aren't going through the external address. I find > that unbound is much easier to configure than bind. Well, if you learn both from scratch, maybe you are right. But after years of bind administration, I would not change just for some no extra effort worth home environment. But the pkgsrc idea was quite good! My BSD user friends mentioned this a lot; just until this point there were no use case for me to try this stuff. Well, I have to admit this was just the right place to try pkgsrc. It's quite good stuff. Also started to play with ansible at the same time to automate the installation and maintenance of zones. It's a nice thing that ansible has modules to manage pkgin, pkg5, and smf services. Cheers, Gyu ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
