Re: [OpenIndiana-discuss] SSDs honoring cache flush?

[Roy Sigurd Karlsbakk]

> I thought there were perfomance issues with using SLOGs in general on
> OI since 148?

Do you have any data on that one? An issue number? Something?

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
r...@karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er 
et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av 
idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og 
relevante synonymer på norsk.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] SSDs honoring cache flush?

[Robbie Crash]

I thought there were perfomance issues with using SLOGs in general on OI
since 148?

On Tue, Apr 24, 2012 at 16:11, Richard Elling <
richard.ell...@richardelling.com> wrote:

> On Apr 24, 2012, at 12:35 PM, Roy Sigurd Karlsbakk wrote:
>
> > Hi all
> >
> > There was a discussion some time back about some (or most?) SSDs not
> honoring cache flushes, that is, something is written to, say, the SLOG,
> and ZFS sends a flush(), the SSD issues a NOP and falsely acknowledges the
> flush.
>
> Some people accused SSD vendors of not honoring cache flush. IIRC, the
> allegations were not proven.
>
> >
> > Now, I've gotten an offer for an SSD that looks good for SLOG, OCZ
> Deneva 2 C SLC 30GB 2.5" SSD. This does not have supercap, but so long as
> it honors cache flush, then it won't make a huge difference, since if a
> write() happens, the SSD cache is flushed to the SSD media, this probably
> won't take more than a handful of milliseconds, and the difference between
> that and backing up the cache, seems minimal.
>
> I've known people to use that SSD without issue.
>
> Here is an article that sheds a little bit of light on the various SSD
> designs. Unfortunately, it does not address the issue that HDDs have
> with their volatile caches and why cache flush commands are so important.
>
> http://www.storagesearch.com/ssd-power-going-down.html
>
>  -- richard
>
> --
> ZFS Performance and Training
> richard.ell...@richardelling.com
> +1-760-896-4422
>
>
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>



-- 
Seconds to the drop, but it seems like hours.

http://www.eff.org/
http://creativecommons.org/
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] SSDs honoring cache flush?

[Richard Elling]

On Apr 24, 2012, at 12:35 PM, Roy Sigurd Karlsbakk wrote:

> Hi all
> 
> There was a discussion some time back about some (or most?) SSDs not honoring 
> cache flushes, that is, something is written to, say, the SLOG, and ZFS sends 
> a flush(), the SSD issues a NOP and falsely acknowledges the flush. 

Some people accused SSD vendors of not honoring cache flush. IIRC, the 
allegations were not proven.

> 
> Now, I've gotten an offer for an SSD that looks good for SLOG, OCZ Deneva 2 C 
> SLC 30GB 2.5" SSD. This does not have supercap, but so long as it honors 
> cache flush, then it won't make a huge difference, since if a write() 
> happens, the SSD cache is flushed to the SSD media, this probably won't take 
> more than a handful of milliseconds, and the difference between that and 
> backing up the cache, seems minimal.

I've known people to use that SSD without issue.

Here is an article that sheds a little bit of light on the various SSD
designs. Unfortunately, it does not address the issue that HDDs have
with their volatile caches and why cache flush commands are so important.

http://www.storagesearch.com/ssd-power-going-down.html

 -- richard

--
ZFS Performance and Training
richard.ell...@richardelling.com
+1-760-896-4422



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] SSDs honoring cache flush?

[Roy Sigurd Karlsbakk]

Hi all

There was a discussion some time back about some (or most?) SSDs not honoring 
cache flushes, that is, something is written to, say, the SLOG, and ZFS sends a 
flush(), the SSD issues a NOP and falsely acknowledges the flush. 

Now, I've gotten an offer for an SSD that looks good for SLOG, OCZ Deneva 2 C 
SLC 30GB 2.5" SSD. This does not have supercap, but so long as it honors cache 
flush, then it won't make a huge difference, since if a write() happens, the 
SSD cache is flushed to the SSD media, this probably won't take more than a 
handful of milliseconds, and the difference between that and backing up the 
cache, seems minimal.

Still, does today's SSDs honor cache flush, or do they still lie about it to 
look better in benchmarks?

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
r...@karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er 
et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av 
idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og 
relevante synonymer på norsk.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] about chromiun

[Apostolos Syropoulos]

> It also works although despite 
> Under the Bonnet -> Content Settings saying Allow Local data under cookies it 
> doesn't seem to allow said cookies.
> Also there appear to be some slight permission problems but it is a start.
> 
 
Disable cookies and JavaScript, close the window, connect to some
site, and then renable them. This worked with aol mail account.

A.S.

--
Apostolos Syropoulos
Xanthi, Greece


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] NFSv4 problems between Ubuntu 10.04 and OI 151a

[Albert Chin]

We have an oi_151a server as our NFS/ZFS/iSCSI server. We have one
interface (aggregated across two physical interfaces) dedicated to NFS
traffic. We wanted to add a second interface dedicated to KVM guest
disk image I/O traffic.

(Solaris NFS server)
# cat /etc/release
  OpenIndiana Development oi_151a X86
Copyright 2010 Oracle and/or its affiliates. All rights reserved.
Use is subject to license terms.
   Assembled 01 September 2011
# ifconfig aggr0 (sanji.il.thewrittenword.com)
aggr0: flags=1000843 mtu 1500 index 2
inet 10.191.57.70 netmask ff00 broadcast 10.191.57.255
# ifconfig igb2 (sanji.vmnfs.il.thewrittenword.com)
igb2: flags=1000843 mtu 1500 index 5
inet 10.191.62.1 netmask ff00 broadcast 10.191.62.255

One of our NFS clients is an Ubuntu Lucid 10.04LTS server:
# ifconfig eth0 (trunks.il.thewrittenword.com)
eth0  Link encap:Ethernet  HWaddr 00:1e:67:1c:fd:d4  
  inet addr:10.191.57.22  Bcast:10.191.57.255 Mask:255.255.255.0
  inet6 addr: fe80::21e:67ff:fe1c:fdd4/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:38915848 errors:0 dropped:6 overruns:6 frame:0
  TX packets:38670920 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:34440950064 (34.4 GB)  TX bytes:47295732818 (47.2 GB)
  Memory:b1d2-b1d4 
# ifconfig eth5 (trunks.vmnfs.il.thewrittenword.com)
eth5  Link encap:Ethernet  HWaddr 00:1b:21:d3:f6:09  
  inet addr:10.191.62.2  Bcast:10.191.62.255 Mask:255.255.255.0
  inet6 addr: fe80::21b:21ff:fed3:f609/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:23382 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1075 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1915540 (1.9 MB)  TX bytes:140018 (140.0 KB)
  Memory:b1b0-b1b8 

NFSv4 mounts between 10.191.57.22 on the Ubuntu client and
10.191.57.70 on the OpenSolaris server work fine:
  (Ubuntu client)
  # nfsstat -m
  /opt/tww from sanji:/opt/tww/
   Flags: 
rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.191.57.22,minorversion=0,local_lock=none,addr=10.191.57.70

  /opt/vms from sanji:/opt/vms/
   Flags: 
rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.191.57.22,minorversion=0,local_lock=none,addr=10.191.57.70

  # ls -l /opt/vms
  total 3567662
  drwxr-xr-x  5 root root  5 2011-09-07 12:52 esxi
  drwxr-xr-x  7 root root  7 2011-11-15 01:38 images
  drwxrwxr-x 81 root root 81 2012-04-19 17:48 iso
  drwxr-xr-x  6 root root  6 2012-04-24 06:19 kvm
  -rw-rw-rw-  1 root root7610401 2011-12-09 02:14 ogata-boot.tar.bz2
  -rw-rw-rw-  1 root root 4852152320 2011-12-09 02:29 ogata-root.tar
  -rw---  1 root root 1001652224 2011-12-09 03:13 ogata-root.tar.bz2
  drwxrwxrwt 23 root src  23 2011-02-04 18:33 vmwareserver

Now, if I try to mount on the second set of interfaces:
  (Ubuntu client)
  # mount sanji:/opt/vms /mnt
  # nfsstat -m
  /mnt from sanji.vmnfs:/opt/vms/
   Flags: 
rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.191.62.2,minorversion=0,local_lock=none,addr=10.191.62.1
  # ls -l /mnt
  total 3
  drwxr-xr-x 7 root root 7 2011-11-15 01:38 images
  # mount sanji.vmnfs:/opt/tww /mnt
  mount.nfs: access denied by server while mounting sanji.vmnfs:/opt/tww

  (Solaris NFS server)
  # zfs get sharenfs tww/opt/vms
  tww/opt/vms  sharenfs 
rw,root=trunks.il.thewrittenword.com:trunks.iscsi.il.thewrittenword.com:trunks.vmnfs.il.thewrittenword.com
 local
  # zfs get sharenfs tww/opt/tww
  tww/opt/tww  sharenfs rw=.il.thewrittenword.com:.vmnfs.il.thewrittenword.com  
local
  # sharemgr show -vp zfs
  ...
  zfs/tww/opt/vms nfs=() 
nfs:sys=(root="trunks.il.thewrittenword.com:trunks.iscsi.il.thewrittenword.com:trunks.vmnfs.il.thewrittenword.com"
 rw="*")
/opt/vms
/opt/vms/images
/opt/vms/images/hpvm
/opt/vms/images/kvm
/opt/vms/images/vios
/opt/vms/images/vmware
/opt/vms/images/xen
  ...

Why doesn't ls -l of /opt/vms look like ls -l of /mnt? And how can I
get them to behave the same?

-- 
albert chin (openindiana-disc...@mlists.thewrittenword.com)

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OT postfix v.s Qmail

[Dan Swartzendruber]

On 4/24/2012 12:43 PM, Gary Gendel wrote:

Dan,

I've been using qmail since the end of the 80's

Yes, greylisting is a powerful tool.  I get that with spamdyke for 
qmail.  Spamdyke and mailfront were the two biggest reasons that I 
stayed with qmail so long.


I saw two greylisting packages for postfix when I was doing my 
searching.  I'm convinced that I want to go to postfix, but it looks 
like it will be a painful transition.


I've got two chains.  One from port 25 that uses spamdyke, and one 
from port 587 that uses mailfront (to give me SSL/TLS and 
authorization).  Since they both converge at the qmail-queue process 
that handles the delivery portion, it's a nice clean path to 
delivery.  I may try to use postfix to replace one first so I can 
really thresh out the issues.


Gary, have you visited the postfix site?  There are howtos for a bunch 
of these issues.  It really shouldn't need to be painful or tricky.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OT postfix v.s Qmail

[Gary Gendel]

Dan,

I've been using qmail since the end of the 80's

Yes, greylisting is a powerful tool.  I get that with spamdyke for 
qmail.  Spamdyke and mailfront were the two biggest reasons that I 
stayed with qmail so long.


I saw two greylisting packages for postfix when I was doing my 
searching.  I'm convinced that I want to go to postfix, but it looks 
like it will be a painful transition.


I've got two chains.  One from port 25 that uses spamdyke, and one from 
port 587 that uses mailfront (to give me SSL/TLS and authorization).  
Since they both converge at the qmail-queue process that handles the 
delivery portion, it's a nice clean path to delivery.  I may try to use 
postfix to replace one first so I can really thresh out the issues.


Gary

On 4/24/12 12:05 PM, Dan Swartzendruber wrote:


I am a long-time postfix user.  The single biggest winner is 
greylisting.  As I recall, there are a couple of greylist packages you 
can plug into postfix and it just works.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OT postfix v.s Qmail

[Dan Swartzendruber]

I am a long-time postfix user.  The single biggest winner is 
greylisting.  As I recall, there are a couple of greylist packages you 
can plug into postfix and it just works.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OT postfix v.s Qmail

[låzaro]

answer in lines...

Thread name: "Re: [OpenIndiana-discuss] OT postfix v.s Qmail" 
Mail number: 22 
Date: Tue, Apr 24, 2012 
In reply to: Gary Gendel  
>
> Låzaro,
> 
> Thanks for the pointer.  Policy-light is much closer to spamdyke's
> capabilities than postfix is.  The big difference is that qmail uses
> process chaning and passes information via environment variables
> where postfix uses a database to provide the information and proxies
> to the modules.  As it hasn't reached version 1 yet, the system is
> still in flux.
> 
> The advantage of qmail's approach is that the work is partitioned by
> executing functionality as needed and the chain is completely
> segregated from other sessions.  Postfix requires executing
> auxiliary services which requires either a proliferation of smaller
> databases or one large database with access locks.
I"m not clear just now but I think, when Postfix make querry to BL DNS
him don't use database, just make a lookup, repeat "I'm not pretty shure
about that". Anyway... I think who use database is more "better" than
system variables, their data don't go flying when the come the blackuots.

Also: "more services, more separate, more secure". Of corse, in the
light-weight balancing load, Qmail have the novell price (use it onle
when needed) but I don't change lightness for security. Also repeat:
I love Qmail, but is a very good idea with very old implementation(s).


> 
> The advantage of postfix's approach is the single arbitrator of what
> is going on so the modules are stateless.  Qmail relies on the
> handoff continue where the previous one left off.  If they read from
> the socket (which is connected to stdin), then they must convey this
> information (using stdout) to the next in the sequence. Thus it must
> store this information if required.  This becomes an issue when
> dealing with a module like SpamAssassin.  In this case, the
> interface, saves the necessary information into a file, let's
> spamassassin process it, and then replay the file to the next item
> in the chain.  On the other hand, postfix's modules rely on postfix
> to collect all the information they need to do their job apriori.
For fight with spam just reject_rbl is enough. Usage of spam-asassim is
very wheigth, heavy (for my old comuter server) the load growht much,
much better consult DNS-BL direct, also more updated. Policyd just done
that but also use cache and save bandwith (very important here) Policyd
also make tarpiting, is an all in one. Very good, but.. if their fail,
all the mail will bty rejected, that never happen to me but is a
posibility...



> 
> This is been a very useful side discussion for me.  We all have our
> biases, mine is based upon familiarity but I can see the writing on
> the wall so this is just an intellectual discussion.
> 
> Gary

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OT postfix v.s Qmail

[Gary Gendel]

Låzaro,

Thanks for the pointer.  Policy-light is much closer to spamdyke's 
capabilities than postfix is.  The big difference is that qmail uses 
process chaning and passes information via environment variables where 
postfix uses a database to provide the information and proxies to the 
modules.  As it hasn't reached version 1 yet, the system is still in flux.


The advantage of qmail's approach is that the work is partitioned by 
executing functionality as needed and the chain is completely segregated 
from other sessions.  Postfix requires executing auxiliary services 
which requires either a proliferation of smaller databases or one large 
database with access locks.


The advantage of postfix's approach is the single arbitrator of what is 
going on so the modules are stateless.  Qmail relies on the handoff 
continue where the previous one left off.  If they read from the socket 
(which is connected to stdin), then they must convey this information 
(using stdout) to the next in the sequence. Thus it must store this 
information if required.  This becomes an issue when dealing with a 
module like SpamAssassin.  In this case, the interface, saves the 
necessary information into a file, let's spamassassin process it, and 
then replay the file to the next item in the chain.  On the other hand, 
postfix's modules rely on postfix to collect all the information they 
need to do their job apriori.


This is been a very useful side discussion for me.  We all have our 
biases, mine is based upon familiarity but I can see the writing on the 
wall so this is just an intellectual discussion.


Gary

On 4/24/12 10:52 AM, låzaro wrote:

due my response, the subject will by a OT

Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?"
Mail number: 20
Date: Tue, Apr 24, 2012
In reply to: Gary Gendel

With all this discussion about Postfix vs. Qmail, I started looking
at what it would take to replace my Qmail installation with Postfix.
I started looking at what it would take to replace spamdyke with
postfix functionality.  Most things have a direct correlation.  One
case so far, greylisting, requires running an independent email
proxy for postfix where it is incorporated in spamdyke.  I'm still
working through the list but many of the configuration options need
more detailed documentation or I'll have to work through the code to
see exactly what it's trying to accomplish.  For example, it took me
quite awhile to dig out how postfix handles CIDR notation.

The pipeline architecture of qmail has been instrumental at making
third-party additions incredibly simple. You can easily plug in
special debugging modules, and even tee off things so you can test
new modules in parallel with real operations.  Before spamdyke was
available, I had developed a number of homebrew modules for spam
analysis and control.  That said, qmail isn't 100% sendmail
compatible, so occasionally I ran into issues with unhandled
sendmail options (until patched).  I don't know whether postfix
suffers from the same issue yet.

Fight with the spam is easy and part of the system to

I paste my full defense here:

smtpd_recipient_restrictions =
 reject_unlisted_sender,
 reject_unlisted_recipient,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unknown_recipient_domain,
 reject_unverified_recipient,
 reject_invalid_hostname,
 reject_unauth_pipelining,
 reject_rbl_client bl.spamcop.net,
 reject_rbl_client sbl.spamhaus.org,
 #check_policy_service inet:127.0.0.1:12525,
 reject_unauth_destination

the line reject_rbl_client consult directly the DNS black list

Also the comented line "#check_policy_service" is a super simply Balck
lis consultating app. At my blog (sorry: in spanish) you can see how to
make it work. Just look at the commands, not see the explaniation, is
not so necesary if follow the step.

http://otherlinuxblog.blogspot.com/2012/01/policyd-light-y-posftix.html


Note:

The reject_rbl_client reject the conection in the moment when the
spammer say MAIL FROM: only with reject_rbl_client you can be quite sure.




Since my Qmail based system does not inherently support IPV6 and
would require significant patching I'm committed to move to Postfix
before this becomes necessary.  However, Postfix configuration is
far more complex if you are someone that likes to understand the
purpose of each option and it's impact to other options.

hard to understand is Exim, postfix is just "diferent" but is full
docuemnted. If you wanna "shot yourself in the foot" just put in google
"postfix shoot myself in the foot" The configuration is "simple" (not
easy) but simple and logic (as Qmail)

As you can see, if read carefully the reject_ lines, it form at the name
explicity good.


  I will
also miss the simplicity of making a split-horizon caching DNS
service via dnscache/tinydns when I need to go to IPV6 which is an
important piece of any email system in a private networked LAN.

well, you k

[OpenIndiana-discuss] OT postfix v.s Qmail

[låzaro]

due my response, the subject will by a OT

Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?" 
Mail number: 20 
Date: Tue, Apr 24, 2012 
In reply to: Gary Gendel  
>
> With all this discussion about Postfix vs. Qmail, I started looking
> at what it would take to replace my Qmail installation with Postfix.
> I started looking at what it would take to replace spamdyke with
> postfix functionality.  Most things have a direct correlation.  One
> case so far, greylisting, requires running an independent email
> proxy for postfix where it is incorporated in spamdyke.  I'm still
> working through the list but many of the configuration options need
> more detailed documentation or I'll have to work through the code to
> see exactly what it's trying to accomplish.  For example, it took me
> quite awhile to dig out how postfix handles CIDR notation.
> 
> The pipeline architecture of qmail has been instrumental at making
> third-party additions incredibly simple. You can easily plug in
> special debugging modules, and even tee off things so you can test
> new modules in parallel with real operations.  Before spamdyke was
> available, I had developed a number of homebrew modules for spam
> analysis and control.  That said, qmail isn't 100% sendmail
> compatible, so occasionally I ran into issues with unhandled
> sendmail options (until patched).  I don't know whether postfix
> suffers from the same issue yet.

Fight with the spam is easy and part of the system to

I paste my full defense here:

smtpd_recipient_restrictions =
reject_unlisted_sender,
reject_unlisted_recipient,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unverified_recipient,
reject_invalid_hostname,
reject_unauth_pipelining,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
#check_policy_service inet:127.0.0.1:12525,
reject_unauth_destination

the line reject_rbl_client consult directly the DNS black list

Also the comented line "#check_policy_service" is a super simply Balck
lis consultating app. At my blog (sorry: in spanish) you can see how to
make it work. Just look at the commands, not see the explaniation, is
not so necesary if follow the step.

http://otherlinuxblog.blogspot.com/2012/01/policyd-light-y-posftix.html


Note:

The reject_rbl_client reject the conection in the moment when the
spammer say MAIL FROM: only with reject_rbl_client you can be quite sure.



> 
> Since my Qmail based system does not inherently support IPV6 and
> would require significant patching I'm committed to move to Postfix
> before this becomes necessary.  However, Postfix configuration is
> far more complex if you are someone that likes to understand the
> purpose of each option and it's impact to other options.
hard to understand is Exim, postfix is just "diferent" but is full
docuemnted. If you wanna "shot yourself in the foot" just put in google
"postfix shoot myself in the foot" The configuration is "simple" (not
easy) but simple and logic (as Qmail)

As you can see, if read carefully the reject_ lines, it form at the name
explicity good.

>  I will
> also miss the simplicity of making a split-horizon caching DNS
> service via dnscache/tinydns when I need to go to IPV6 which is an
> important piece of any email system in a private networked LAN.

well, you killme at this point. DNS is not under my control here

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] about chromiun

[Paul Johnston]

I tried the download on my machine, a Dell Optiplex 780 
SunOS openindiana 5.11 oi_151a3 i86pc i386 i86pc Solaris

It also works although despite 
Under the Bonnet -> Content Settings saying Allow Local data under cookies it 
doesn't seem to allow said cookies.
Also there appear to be some slight permission problems but it is a start.


Paul


From: Dietmar Sovonja [juhuu2...@gmx.de]
Sent: 19 April 2012 15:17
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] about chromiun

Hi låzaro,

try to download this build for Solaris 11 and unzip it:
http://chromium.hybridsource.org/chromium-solaris-10.0.648.204.tar.bz2 .

It works on my computer.

Regards,
Dietmar


On 17.04.12 04:15, låzaro wrote:
> Hello:
>
> Press "play" and the voice say "my english is not very good"
>
> After many time of question at IRC about how to load linux from the OI
> grub it still missworking. So... I will build my new home in SunOS.
>
> My question:
>
>  From where or how can obtain Chromium web browser for OI?
>
> Because in the wiki and google talk about "oh yeah, Finally!" But...
> Where is the download link?
>
>
>
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?

[Gary Gendel]

With all this discussion about Postfix vs. Qmail, I started looking at 
what it would take to replace my Qmail installation with Postfix.  I 
started looking at what it would take to replace spamdyke with postfix 
functionality.  Most things have a direct correlation.  One case so far, 
greylisting, requires running an independent email proxy for postfix 
where it is incorporated in spamdyke.  I'm still working through the 
list but many of the configuration options need more detailed 
documentation or I'll have to work through the code to see exactly what 
it's trying to accomplish.  For example, it took me quite awhile to dig 
out how postfix handles CIDR notation.


The pipeline architecture of qmail has been instrumental at making 
third-party additions incredibly simple. You can easily plug in special 
debugging modules, and even tee off things so you can test new modules 
in parallel with real operations.  Before spamdyke was available, I had 
developed a number of homebrew modules for spam analysis and control.  
That said, qmail isn't 100% sendmail compatible, so occasionally I ran 
into issues with unhandled sendmail options (until patched).  I don't 
know whether postfix suffers from the same issue yet.


Since my Qmail based system does not inherently support IPV6 and would 
require significant patching I'm committed to move to Postfix before 
this becomes necessary.  However, Postfix configuration is far more 
complex if you are someone that likes to understand the purpose of each 
option and it's impact to other options.  I will also miss the 
simplicity of making a split-horizon caching DNS service via 
dnscache/tinydns when I need to go to IPV6 which is an important piece 
of any email system in a private networked LAN.


Gary

On 4/24/12 8:44 AM, låzaro wrote:

anyway... postfix is the better today :D

I saw using Qmail long time ago, I like it, but is obsolete

Also, I have my compiled Qmail and configured just as "personal email
museum"

Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?"
Mail number: 17
Date: Tue, Apr 24, 2012
In reply to: Christopher Chan

On Monday, April 23, 2012 08:44 PM, låzaro wrote:

in Qmail, the security is patch-maked in postfix is by-design-maked

NO, that is not accurate. "security" where it means anti-spam, DJB
did not bother because as far as he is concerned, the way things
are, things are just broken. Too bad his idea of how email should
work never took off. So any anti-spam features are provided by
THIRD-PARTIES. It is not 'patch-maked'. There is zero anti-spam.

As for postfix, 'by-design-maked' just means Wietse put in the time
to develop postfix unlike DJB who stopped in 1998.


for example, smtp auth, SASL, TLS and soon. Also postfix is more
modular. You can use it with someSQL LDAP and all thats cute things.

There is a qmail fork that does both sql and ldap too. postfix is
only better because its developer continued to work on the code and
keep up with the times and he built a good reputation while at it.

No qmail fork has ever managed that because of DJB's stand on
licensing but now that qmail is public domain, maybe in the future
one of these forks might.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?

[Jonathan Adams]

Dovecot's take on Qmail (and other MTA's http://wiki.dovecot.org/MTA )
which states "qmail is an obsolete and unmaintained server. Its POP3
part can be taken over by Dovecot. Qmail started off boasting about
speed and security in the mid-1990s, but has lots of unfixed bugs
(this document includes patches where known), among them security bugs
that remain unfixed, and the security guarantee (500 USD) denied. If
you really intend to continue using it, read Dave Sill's Life with
qmail which contains instructions to work around some of qmail's
security issues. "



On 24 April 2012 13:44, låzaro  wrote:
> anyway... postfix is the better today :D
>
> I saw using Qmail long time ago, I like it, but is obsolete
>
> Also, I have my compiled Qmail and configured just as "personal email
> museum"
>
> Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?"
> Mail number: 17
> Date: Tue, Apr 24, 2012
> In reply to: Christopher Chan 
>>
>> On Monday, April 23, 2012 08:44 PM, låzaro wrote:
>> >in Qmail, the security is patch-maked in postfix is by-design-maked
>>
>> NO, that is not accurate. "security" where it means anti-spam, DJB
>> did not bother because as far as he is concerned, the way things
>> are, things are just broken. Too bad his idea of how email should
>> work never took off. So any anti-spam features are provided by
>> THIRD-PARTIES. It is not 'patch-maked'. There is zero anti-spam.
>>
>> As for postfix, 'by-design-maked' just means Wietse put in the time
>> to develop postfix unlike DJB who stopped in 1998.
>>
>> >for example, smtp auth, SASL, TLS and soon. Also postfix is more
>> >modular. You can use it with someSQL LDAP and all thats cute things.
>>
>> There is a qmail fork that does both sql and ldap too. postfix is
>> only better because its developer continued to work on the code and
>> keep up with the times and he built a good reputation while at it.
>>
>> No qmail fork has ever managed that because of DJB's stand on
>> licensing but now that qmail is public domain, maybe in the future
>> one of these forks might.
>>
>> ___
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss@openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
> --
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?

[låzaro]

anyway... postfix is the better today :D

I saw using Qmail long time ago, I like it, but is obsolete

Also, I have my compiled Qmail and configured just as "personal email
museum"

Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?" 
Mail number: 17 
Date: Tue, Apr 24, 2012 
In reply to: Christopher Chan  
>
> On Monday, April 23, 2012 08:44 PM, låzaro wrote:
> >in Qmail, the security is patch-maked in postfix is by-design-maked
> 
> NO, that is not accurate. "security" where it means anti-spam, DJB
> did not bother because as far as he is concerned, the way things
> are, things are just broken. Too bad his idea of how email should
> work never took off. So any anti-spam features are provided by
> THIRD-PARTIES. It is not 'patch-maked'. There is zero anti-spam.
> 
> As for postfix, 'by-design-maked' just means Wietse put in the time
> to develop postfix unlike DJB who stopped in 1998.
> 
> >for example, smtp auth, SASL, TLS and soon. Also postfix is more
> >modular. You can use it with someSQL LDAP and all thats cute things.
> 
> There is a qmail fork that does both sql and ldap too. postfix is
> only better because its developer continued to work on the code and
> keep up with the times and he built a good reputation while at it.
> 
> No qmail fork has ever managed that because of DJB's stand on
> licensing but now that qmail is public domain, maybe in the future
> one of these forks might.
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

-- 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Using OI as a combined storage serverandvirtual server enviroment

[Richard PALO]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Virtualbox supports headless deployments just fine (just use
VBoxManage commands instead of VirtualBox), no more complexe than any
other solution, it's even documented.

Evidently licensing is more the problem...
... hence the benefit of KVM
(and for those on AMD, that AMD SVM support continues to improve!)



Le 23/04/12 14:38, Dan Swartzendruber a écrit :
> I would argue that running a GUI on top of OI so that you can run
> VMs under virtualbox carries the same complexity (if I'm wrong,
> where is the extra layer?)  Also, I wasn't aware of your HW
> limitations - AFAIK you never stated them.  I don't think either
> solution is better or more complicated - nor did I say so - just an
> alternative.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPll3oAAoJECAB22fHtp27d3IH/01mRD1EFNPUqnUk6kJdOhsr
BHvDfWAUyBKycV3f2tmIsXi2SPn7hb19S7/8CzPJysqcBvVVVvFgRq8o9wNOrHGq
+eL72RBBeTO2p+gkSjp1iYxVb3iRxmU9Aw8GAhzQFL3DN5MIQ7SCSDdQT9Do7sj/
Uuh6QFbF/vQWT1oXnYqYLbIERyn6QyLzs5Gr/6XvHd20vmMarrQTHk5BUkMYKnLB
hyoFZvCeQqao7ioKhdaeCW8U1zx0L4B3kL4zfbl34PDO91TEkDVupLOBNTiFu3sY
HOH9vJoAZgK5rY1ivxsSX7uyZe9r7/1EMUVM5PtJH8U1O8VMNlyKAo0z4wWeMVQ=
=jk+p
-END PGP SIGNATURE-


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss