Re: [OpenIndiana-discuss] Workaround for Flash Plugin using older one
On 9 July 2013 16:12, Paolo Marcheschi wrote: > Hi > > I found a workaround for flash plugin in order to see youtube and other > flash sites, What was the original problem with the new flash plugin? > I used the archived flashplayer10_1r53_64_solaris_x86.tar.bz2 from > http://fpdownload.macromedia.com/get/flashplayer/installers/archive/fp10.1_archive.zip > > remove the newest plugin, and copy the old one in .mozilla/plugins folder. > > use the r53 instead of the r82, because the r82 does not work on other sites > (i.e. grooveshark) > to avoid activate the plugin every time follow this guide: > http://mzl.la/R7DD9y > > I Hope this helps. > > Ciao > > Paolo > > > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss Lionel ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Inefficient zvol space usage on 4k drives
On 8 August 2013 17:11, Richard Elling wrote: > On Aug 7, 2013, at 2:50 PM, Jason Lawrence wrote: > >> This might be a better question for the Illumos group, so please let me know. >> >> I have a zvol for a KVM instance which I felt was taking up too much space. >> After doing a little research, I stumbled upon >> http://support.freenas.org/ticket/2383 and repeated the test on my machine. >> I'm running a RAIDZ2 pool with eight "advanced format" 4k sector drives. I >> created the pool with ashift=12 with this in mind. >> >> root@hostname:~# zfs create -V 20g -o volblocksize=32k storage/testbed/32k >> root@hostname:~# zfs create -V 20g -o volblocksize=8k storage/testbed/8k >> >> root@hostname:~# dd if=/dev/zero of=/dev/zvol/rdsk/storage/testbed/32k >> bs=1048576 count=20400 >> 20400+0 records in >> 20400+0 records out >> 21390950400 bytes (21 GB) copied, 493.836 s, 43.3 MB/s >> >> root@hostname:~# dd if=/dev/zero of=/dev/zvol/rdsk/storage/testbed/8k >> bs=1048576 count=20400 >> >> 20400+0 records in >> 20400+0 records out >> 21390950400 bytes (21 GB) copied, 548.916 s, 39.0 MB/s >> >> root@hostname:~# zfs list | grep testbed >> storage/testbed 64.2G 5.79T 307K /storage/testbed >> storage/testbed/32k 21.3G 5.79T 21.3G - >> storage/testbed/8k 42.8G 5.79T 42.8G - >> >> >> The 8k blocksize zvol takes up twice the space of the 32k blocksize zvol. As >> 8k is the default, this must be affecting others... > > This is expected. For 4K sector sizes and > 9 disks per raidz2 set: > volblocksize = 8k, raidz2 writes 2 data (8k) + 2 parity (8k) [like > mirroring] > volblocksize = 32k, raidz2 writes 8 data (32k) + 2 parity (8k) [like > RAID-6] > > What most folks miss is: > volblocksize = 4k, raidz2 writes 1 data (4k) + 2 parity (8k) [like > triple mirroring] > > so, don't do 4k recordsize with 4K sector disks unless you are mirroring. What about disks (i.e. iSCSI connected to a hardware raid; the larger sector size is intentional to improve throughput) which have even larger sectors, e.g. 8k sectors? Lionel ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Split-root installations
On 26 November 2013 19:23, Irek Szczesniak wrote:
> On Tue, Nov 26, 2013 at 7:07 PM, Jim Klimov wrote:
>> On 2013-11-26 17:25, Jim Klimov wrote:
>>>
>>> On 2013-11-17 03:50, Jim Klimov wrote:
For years I've mentioned "split-root" installations of Solaris-like
systems in such a way that the root filesystem (the BE) is represented
by several datasets, such as a split-off /usr dataset. Also there may
be some datasets shared between boot environments, such as the sinks
for logs and crashdumps, and not all of these are required to live on
the rpool at all. There are cases when all such tweaks may be desirable.
>>>
>>>
>>> WARNING
>>>
>>> As discussed in another thread, it was discovered that the SMF methods
>>> for network/physical (both :default and :nwam) use many programs from
>>> /usr, and are executed before the /usr filesystem is actually mounted
>>> in case of a split-root installation. This tanks the NWAM setups, but
>>> the default ones (based on static files in /etc) succeeds for both DHCP
>>> and completely static addressing.
>>>
>>> I hope to fix this somehow, but a head-on approach failed: the "root"
>>> filesystem and other FS services depend on svc:/system/identity:node
>>> (indirectly via svc:/system/metainit:default) and that depends on
>>> svc:/network/physical... loop and maintenance... Disabling the metainit
>>> service does not help fix the dependency_cycle condition :\
>>
>>
>> A similar problem is logged in "iptun" service as well:
>>
>> # grep 'not found' /etc/svc/volatile/*log
>> /etc/svc/volatile/network-iptun:default.log:/lib/svc/method/net-iptun: line
>> 81: /usr/bin/cut: not found
>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical:
>> line 722: /usr/bin/nawk: not found
>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]:
>> /usr/bin/sort: not found [No such file or directory]
>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical:
>> line 733: cat: not found
>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]:
>> /usr/bin/nawk: not found [No such file or directory]
>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[317]:
>> /usr/bin/cut: not found [No such file or directory]
>> ...
>>
>> But it does at least depend on "physical" and if that would be fixed
>> by revised dependencies (to run when /usr is properly present) - so
>> should be "iptun".
>
> cut, cat and grep are ksh builtins. Use builtin (run builtin
> --man to read details) to enable them by default and then remove the
> absolute paths so the shell doesn't search PATH for them.
> Most nawk usage can be replaced by ksh pattern matching, leaving
> sort(1) as the only command to worry about.
Here is a small "nano" version of sort(1). More complex sorting can be
archived by modifying the key= statement with printf, but be careful
to consider duplicate keys (hence the use of counter variable k in my
example):
ksh -c 'function nanosort { typeset -A a ; integer k=0; while read i ;
do key="$i$((k++))" a[$key]="$i" ; done ; printf "%s\n" "${a[@]}" ; }
; seq 14 | nanosort'
1
10
11
12
13
14
2
3
4
5
6
7
8
9
Lionel
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Split-root installations
On 27 November 2013 00:34, Lionel Cons wrote:
> On 26 November 2013 19:23, Irek Szczesniak wrote:
>> On Tue, Nov 26, 2013 at 7:07 PM, Jim Klimov wrote:
>>> On 2013-11-26 17:25, Jim Klimov wrote:
>>>>
>>>> On 2013-11-17 03:50, Jim Klimov wrote:
>>>>>
>>>>>For years I've mentioned "split-root" installations of Solaris-like
>>>>> systems in such a way that the root filesystem (the BE) is represented
>>>>> by several datasets, such as a split-off /usr dataset. Also there may
>>>>> be some datasets shared between boot environments, such as the sinks
>>>>> for logs and crashdumps, and not all of these are required to live on
>>>>> the rpool at all. There are cases when all such tweaks may be desirable.
>>>>
>>>>
>>>> WARNING
>>>>
>>>> As discussed in another thread, it was discovered that the SMF methods
>>>> for network/physical (both :default and :nwam) use many programs from
>>>> /usr, and are executed before the /usr filesystem is actually mounted
>>>> in case of a split-root installation. This tanks the NWAM setups, but
>>>> the default ones (based on static files in /etc) succeeds for both DHCP
>>>> and completely static addressing.
>>>>
>>>> I hope to fix this somehow, but a head-on approach failed: the "root"
>>>> filesystem and other FS services depend on svc:/system/identity:node
>>>> (indirectly via svc:/system/metainit:default) and that depends on
>>>> svc:/network/physical... loop and maintenance... Disabling the metainit
>>>> service does not help fix the dependency_cycle condition :\
>>>
>>>
>>> A similar problem is logged in "iptun" service as well:
>>>
>>> # grep 'not found' /etc/svc/volatile/*log
>>> /etc/svc/volatile/network-iptun:default.log:/lib/svc/method/net-iptun: line
>>> 81: /usr/bin/cut: not found
>>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical:
>>> line 722: /usr/bin/nawk: not found
>>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]:
>>> /usr/bin/sort: not found [No such file or directory]
>>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical:
>>> line 733: cat: not found
>>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]:
>>> /usr/bin/nawk: not found [No such file or directory]
>>> /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[317]:
>>> /usr/bin/cut: not found [No such file or directory]
>>> ...
>>>
>>> But it does at least depend on "physical" and if that would be fixed
>>> by revised dependencies (to run when /usr is properly present) - so
>>> should be "iptun".
>>
>> cut, cat and grep are ksh builtins. Use builtin (run builtin
>> --man to read details) to enable them by default and then remove the
>> absolute paths so the shell doesn't search PATH for them.
>> Most nawk usage can be replaced by ksh pattern matching, leaving
>> sort(1) as the only command to worry about.
>
> Here is a small "nano" version of sort(1). More complex sorting can be
> archived by modifying the key= statement with printf, but be careful
> to consider duplicate keys (hence the use of counter variable k in my
> example):
>
> ksh -c 'function nanosort { typeset -A a ; integer k=0; while read i ;
> do key="$i$((k++))" a[$key]="$i" ; done ; printf "%s\n" "${a[@]}" ; }
> ; seq 14 | nanosort'
> 1
> 10
> 11
> 12
> 13
> 14
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
The code has a bug: There must be a ; between key="$i$((k++))" and
a[$key]="$i", otherwise the shell is free to execute both statements
in parallel.
Lionel
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] cifs/server Kerberos support
On 28 April 2016 at 23:24, Ray Van Dolson wrote: > Hi, everyone -- this is OT as it's Nexenta related, but figured you > folks here would know the answer. Also have a question out to Nexenta > support as well. > > We're trying to get MSA's (Managed Service Accounts) to talk to a CIFS > share on a Nexenta 3.1.6 system. I *believe* MSA's require Kerberos, > and it doesn't appear the cifs/smb service on our 3.1.6 box supports > Kerberos authentication, though it is AD joined. > > Can anyone confirm? What will not work because Illumos krb5 is outdated. For AD interoperability you need at least to update Illumos krb5 to MIT krb5 1.12 or better, or you have sporadic outages. Given that Illumos krb5 is heavily modified and has kernel-based add ons its nearly impossible to do except for one of the original SUN engineers who have intimate knowledge of the krb5 update process. Lionel ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] cifs/server Kerberos support
On 29 April 2016 at 00:22, Ray Van Dolson wrote: > On Thu, Apr 28, 2016 at 11:43:48PM +0200, Lionel Cons wrote: >> On 28 April 2016 at 23:24, Ray Van Dolson wrote: >> > Hi, everyone -- this is OT as it's Nexenta related, but figured you >> > folks here would know the answer. Also have a question out to Nexenta >> > support as well. >> > >> > We're trying to get MSA's (Managed Service Accounts) to talk to a CIFS >> > share on a Nexenta 3.1.6 system. I *believe* MSA's require Kerberos, >> > and it doesn't appear the cifs/smb service on our 3.1.6 box supports >> > Kerberos authentication, though it is AD joined. >> > >> > Can anyone confirm? >> >> What will not work because Illumos krb5 is outdated. For AD >> interoperability you need at least to update Illumos krb5 to MIT krb5 >> 1.12 or better, or you have sporadic outages. >> Given that Illumos krb5 is heavily modified and has kernel-based add >> ons its nearly impossible to do except for one of the original SUN >> engineers who have intimate knowledge of the krb5 update process. >> >> Lionel > > Thanks. Could explain why when we add SPNs, Windows clients trying to > access via the SPN alias fail, but Samba still succeeds. Perhaps the > latter is falling back to some other authenticaiton mechanism that > Windows isn't trusting. Possibly due to Extended Security not being > supported? Dunno, but note that SAMBA usually relies on Heimdal Kerberos and not on the MIT Kerberos. Problem with Solaris krb5 is that it lacks a lot of error checking and AD interoperability changes since MIT krb5 1.6 Lionel ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] NVIDIA again
On 14 September 2016 at 00:34, Alan Coopersmith wrote: > On 08/17/16 11:57 AM, Alan Coopersmith wrote: >> >> Note that on Solarish OS'es, the backtrace will sometimes warn you about >> the >> last linker lookup failure, even when it's not relevant - it could be the >> driver looked for that symbol, didn't find it because your Xorg is an >> older >> release, and went on about it's business only to crash later. >> >> (I think, but have not had time to confirm that this is because the code I >> stuck in osinit.c years ago to catch actual errors here fails to check in >> the signal handler what signal was received so prints it for every >> signal: >> >> https://cgit.freedesktop.org/xorg/xserver/commit?id=98f4179156391752e6688339487458ad7828abf4 >> >> If correct, the fix would be to wrap the first chunk of that in >> OsSigHandler inside an "if (signo == SIGQUIT)" block.) > > > Confirmed and fixed upstream since I finally got tired of explaining my bug > to > everyone: > > https://cgit.freedesktop.org/xorg/xserver/commit/?id=75c1d04650f63464263c159d2e95364482be724f > > -alan- Mind fixing the patch and print the siginfo information to the error message to have more diagnostics? Lionel ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
