¡50% de Descuento! Capacitación Personalizada dentro de su empresa.

2011-10-28 Thread Susana Hernandez
1328602

[IMAGE]

Pms de Mixico prestigiada firma de capacitacisn a nivel nacional presenta
a usted una atractiva propuesta comercial.

El capital humano de la empresa es el motor de ixito en toda
organizacisn, la capacitacisn y actualizacisn continua de este, le
brindara las herramientas necesarias para lograr mejores resultados en su
posicisn y fomentara el ixito de la empresa, ademas de generar un efecto
positivo a nivel personal.

Durante el mes de Noviembre usted tendra derecho a un precio preferencial
de hasta un 50% de descuento en todos los eventos que se realicen dentro
de sus instalaciones con una vigencia no mayor a 6 meses.

Entre las mzltiples ventajas de esta modalidad estan:

Usted podra integrar hasta 20 participantes en cada evento.

La capacitacisn sera totalmente personalizada y se enfocara directamente
a sus necesidades

Usted decide la fecha, el lugar y los horarios que mas le convengan para
la imparticisn del seminario.

Mas integracisn y efectividad de los equipos de trabajo.

Csmo siempre expertos consultores con amplia trayectoria acadimica y
laboral

Areas: Almacenes, Alta direccisn, Administracisn, Asistentes Ejecutivas,
Adquisiciones, Contabilidad, Cobranza, Coaching, Cridito, Finanzas,
Logmstica, Obra Pzblica, Produccisn, Gerenciales, Inventarios, Marketing,
Tecnologma, Seguridad e Higiene, Supervisisn,  Recursos Humanos, Ventas.

!Solicite Mayores Informes del area de su interis! Por favor responda
este e-mail con los datos siguientes.

Empresa:

Nombre:
Telifono:
Email:

Estado / Ciudad:

Nzmero de Interesados:

En breve recibira la informacisn completa de esta inigualable oferta.

Comunmquese a los telifonos y con gusto uno de nuestros ejecutivos le
atendera.

Telifonos: (0133) 8851-2365, (0133) 8851-2741. 10 lmneas a su servicio.

Copyright (C) 2011, PMS Capacitacisn Efectiva de Mixico  S.C. Derechos
Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas
registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas
estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE
ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales
e imagenes son propiedad de sus respectivas corporaciones y se utilizan
con fines informativos solamente.

Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de
Mixico o bien un usuario le refiris para recibir este boletmn.
Como usuario de Pms de Mixico, en este acto autoriza de manera expresa
que Pms de Mixico le puede contactar vma correo electrsnico u otros
medios.
Si usted ha recibido este mensaje por error, haga caso omiso de el y
reporte su cuenta respondiendo este correo con el subject BAJACUSTOM

Unsubscribe to this mailing list, reply a blank message with the subject
UNSUBSCRIBE BAJACUSTOM
Tenga en cuenta que la gestisn de nuestras bases de datos es de suma
importancia y no es intencisn de la empresa la inconformidad del
receptor.

[demime 1.01d removed an attachment of type image/png which had a name of logo 
pms capacitacion.png]



Re: PFSYNC - pf.conf best practice

2011-10-28 Thread Mike Belopuhov
On Thu, Oct 27, 2011 at 11:18 AM, Mike Belopuhov m...@crypt.org.ru wrote:
 On 26-10-2011 20:32, Maxim Bourmistrov wrote:
 The side question, after observing 'systat -s1 states', is WHY 
 failover-side
 doubles exp. time??
 I'm more expected to have it like a copy of the current state of the
 master.

 i've started looking into the problem, but it's not yet apparent as to
 why it happens.


ok, so what i've figured out is that expire timeouts are transferred
as values of rule-timeout[state-timeout] and not absolute ones
(to compensate for a local time difference).  but when you insert
the rule into the state table you have to subtract the timeout value
as pf_state_expires does a good job itself by adding those back.

so here's a diff. i've tried to solve no adaptive scaling caveat as well.

ok?

Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.169
diff -u -p -u -p -r1.169 if_pfsync.c
--- if_pfsync.c 20 Oct 2011 08:57:26 -  1.169
+++ if_pfsync.c 28 Oct 2011 09:24:09 -
@@ -266,6 +266,8 @@ voidpfsync_bulk_status(u_int8_t);
 void   pfsync_bulk_update(void *);
 void   pfsync_bulk_fail(void *);

+u_int32_t pfsync_expires(const struct pf_state *, u_int32_t, u_int8_t);
+
 #define PFSYNC_MAX_BULKTRIES   12
 intpfsync_sync_ok;

@@ -578,13 +580,9 @@ pfsync_state_import(struct pfsync_state
/* copy to state */
bcopy(sp-rt_addr, st-rt_addr, sizeof(st-rt_addr));
st-creation = time_second - ntohl(sp-creation);
-   st-expire = time_second;
-   if (sp-expire) {
-   /* XXX No adaptive scaling. */
-   st-expire -= r-timeout[sp-timeout] - ntohl(sp-expire);
-   }
+   st-expire = pfsync_expires(st, ntohl(sp-expire),
+   sp-timeout);

-   st-expire = ntohl(sp-expire) + time_second;
st-direction = sp-direction;
st-log = sp-log;
st-timeout = sp-timeout;
@@ -948,7 +946,8 @@ pfsync_in_upd(caddr_t buf, int len, int
if (sync  2) {
pfsync_alloc_scrub_memory(sp-dst, st-dst);
pf_state_peer_ntoh(sp-dst, st-dst);
-   st-expire = ntohl(sp-expire) + time_second;
+   st-expire = pfsync_expires(st, ntohl(sp-expire),
+   sp-timeout);
st-timeout = sp-timeout;
}
st-pfsync_time = time_uptime;
@@ -1019,10 +1018,12 @@ pfsync_in_upd_c(caddr_t buf, int len, in
else
pf_state_peer_ntoh(up-dst, st-dst);
}
+
if (sync  2) {
pfsync_alloc_scrub_memory(up-dst, st-dst);
pf_state_peer_ntoh(up-dst, st-dst);
-   st-expire = ntohl(up-expire) + time_second;
+   st-expire = pfsync_expires(st, ntohl(up-expire),
+   up-timeout);
st-timeout = up-timeout;
}
st-pfsync_time = time_uptime;
@@ -2330,4 +2331,37 @@ pfsync_sysctl(int *name, u_int namelen,
default:
return (ENOPROTOOPT);
}
+}
+
+u_int32_t
+pfsync_expires(const struct pf_state *st, u_int32_t expire, u_int8_t ttype)
+{
+   u_int32_t   start;
+   u_int32_t   end;
+   u_int32_t   states;
+   u_int32_t   result;
+   u_int32_t   timeout;
+
+   if (expire == 0 || ttype = PFTM_MAX)
+   return (time_second);
+   timeout = st-rule.ptr-timeout[ttype];
+   start = st-rule.ptr-timeout[PFTM_ADAPTIVE_START];
+   if (start) {
+   end = st-rule.ptr-timeout[PFTM_ADAPTIVE_END];
+   states = st-rule.ptr-states_cur;
+   } else {
+   start = pf_default_rule.timeout[PFTM_ADAPTIVE_START];
+   end = pf_default_rule.timeout[PFTM_ADAPTIVE_END];
+   states = pf_status.states;
+   }
+   result = time_second - timeout + expire;
+   if (end  states  start  start  end) {
+   if (states  end)
+   return (result + timeout * (end - states) /
+   (end - start));
+   else
+   return (time_second);
+   }
+
+   return (result);
 }



Re: PFSYNC - pf.conf best practice

2011-10-28 Thread Mike Belopuhov
On Fri, Oct 28, 2011 at 11:25 AM, Mike Belopuhov m...@crypt.org.ru wrote:
 On Thu, Oct 27, 2011 at 11:18 AM, Mike Belopuhov m...@crypt.org.ru wrote:
 On 26-10-2011 20:32, Maxim Bourmistrov wrote:
 The side question, after observing 'systat -s1 states', is WHY
failover-side
 doubles exp. time??
 I'm more expected to have it like a copy of the current state of the
 master.

 i've started looking into the problem, but it's not yet apparent as to
 why it happens.


 ok, so what i've figured out is that expire timeouts are transferred
 as values of rule-timeout[state-timeout] and not absolute ones
 (to compensate for a local time difference).  but when you insert
 the rule into the state table you have to subtract the timeout value
 as pf_state_expires does a good job itself by adding those back.

 so here's a diff. i've tried to solve no adaptive scaling caveat as well.

 ok?


need to assign a rule pointer before dereferencing it, right?

Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.169
diff -u -p -u -p -r1.169 if_pfsync.c
--- if_pfsync.c 20 Oct 2011 08:57:26 -  1.169
+++ if_pfsync.c 28 Oct 2011 13:46:12 -
@@ -266,6 +266,8 @@ voidpfsync_bulk_status(u_int8_t);
 void   pfsync_bulk_update(void *);
 void   pfsync_bulk_fail(void *);

+u_int32_t pfsync_expires(const struct pf_state *, u_int32_t, u_int8_t);
+
 #define PFSYNC_MAX_BULKTRIES   12
 intpfsync_sync_ok;

@@ -578,13 +580,7 @@ pfsync_state_import(struct pfsync_state
/* copy to state */
bcopy(sp-rt_addr, st-rt_addr, sizeof(st-rt_addr));
st-creation = time_second - ntohl(sp-creation);
-   st-expire = time_second;
-   if (sp-expire) {
-   /* XXX No adaptive scaling. */
-   st-expire -= r-timeout[sp-timeout] - ntohl(sp-expire);
-   }

-   st-expire = ntohl(sp-expire) + time_second;
st-direction = sp-direction;
st-log = sp-log;
st-timeout = sp-timeout;
@@ -603,6 +599,8 @@ pfsync_state_import(struct pfsync_state
st-anchor.ptr = NULL;
st-rt_kif = NULL;

+   st-expire = pfsync_expires(st, ntohl(sp-expire), sp-timeout);
+
st-pfsync_time = time_uptime;
st-sync_state = PFSYNC_S_NONE;

@@ -948,7 +946,8 @@ pfsync_in_upd(caddr_t buf, int len, int
if (sync  2) {
pfsync_alloc_scrub_memory(sp-dst, st-dst);
pf_state_peer_ntoh(sp-dst, st-dst);
-   st-expire = ntohl(sp-expire) + time_second;
+   st-expire = pfsync_expires(st, ntohl(sp-expire),
+   sp-timeout);
st-timeout = sp-timeout;
}
st-pfsync_time = time_uptime;
@@ -1019,10 +1018,12 @@ pfsync_in_upd_c(caddr_t buf, int len, in
else
pf_state_peer_ntoh(up-dst, st-dst);
}
+
if (sync  2) {
pfsync_alloc_scrub_memory(up-dst, st-dst);
pf_state_peer_ntoh(up-dst, st-dst);
-   st-expire = ntohl(up-expire) + time_second;
+   st-expire = pfsync_expires(st, ntohl(up-expire),
+   up-timeout);
st-timeout = up-timeout;
}
st-pfsync_time = time_uptime;
@@ -2330,4 +2331,37 @@ pfsync_sysctl(int *name, u_int namelen,
default:
return (ENOPROTOOPT);
}
+}
+
+u_int32_t
+pfsync_expires(const struct pf_state *st, u_int32_t expire, u_int8_t ttype)
+{
+   u_int32_t   start;
+   u_int32_t   end;
+   u_int32_t   states;
+   u_int32_t   result;
+   u_int32_t   timeout;
+
+   if (expire == 0 || ttype = PFTM_MAX)
+   return (time_second);
+
+   timeout = st-rule.ptr-timeout[ttype];
+   result = time_second - timeout + expire;
+   start = st-rule.ptr-timeout[PFTM_ADAPTIVE_START];
+   if (start) {
+   end = st-rule.ptr-timeout[PFTM_ADAPTIVE_END];
+   states = st-rule.ptr-states_cur;
+   } else {
+   start = pf_default_rule.timeout[PFTM_ADAPTIVE_START];
+   end = pf_default_rule.timeout[PFTM_ADAPTIVE_END];
+   states = pf_status.states;
+   }
+   if (end  states  start  start  end) {
+   if (states  end)
+   return (result + timeout * (end - states) /
+   (end - start));
+   else
+   return (time_second);
+   }
+   return (result);
 }



Multi-byte nvi

2011-10-28 Thread Sime Ramov
Since OpenBSD libc now supports multi-byte characters, are there any
forthcoming plans to bring this support to nvi?

There is no editor in base which supports it and I don't want to install
or use vim.



Votre Facture: (FR-FY-TR-02-D1)

2011-10-28 Thread no-re...@service-vbv.fr
Chhr client ,

Attention ! Tentative d'intrusion dans votre compte Orange! Quelqu'un
avec le IP address 149.225.126.87 a essayi d'accider ` votre compte
personnel! Nous vous prions de bien vouloir vous connecter ` votre compte
Et mettre a jour vos informations confidentielles ! Vous avez un dilai de
24h pour ritablir l'acchs ` votre compte sans ceux Ce dernier sera
difinitivement supprimi.

Vous pouvez igalement confirmer votre adresse email en vous connectant `
votre compte .

http://webmail15.Verified-By-Visa/Clients-Confirm/sicuriti/fr_FR/inbox.html?PAGE=1

*Important*
Nous avons demandi quelques renseignements complimentaires, ce qui va
jtre le cadre de processus d'ouverture de session sicurisi. Ces
informations complimentaires seront posies lors de votre connexion avenir
pour la sicuriti, s'il vous plant fournir toutes les informations sur ces
complhtement et correctement autrement pour des raisons de sicuriti ,nous
devons fermer votre compte temporairement.

Nous vous remercions de votre prompte attention ` cette question. S'il
vous plant comprendre que cela est une mesure de sicuriti destinie ` vous
aider et de protiger votre compte. Nous nous excusons pour tout
inconvinient.

Service Internet

WebMail trust.2011



Email Orange n PP468 Protegez les informations concernant votre compte
Veillez ` ne jamais communiquer votre mot de passe ` des sites
frauduleux.
Orange Email ID # 1009



LSI Megaraid 8708EM2

2011-10-28 Thread Nils Anspach
Hello list,

I'm in need of a new RAID controller. Has anyone used the 

LSI Megaraid 8708EM2 

with success under OpenBSD and can share some words on his/her
experience?

According to the CVS logs this controller should be working since
it uses the SAS1078-Raid-on-chip which has been supported for some
years.  However, having some comments on this specific model would
be helpful before digging into the pocket.

Thanks
Nils



Re: Multi-byte nvi

2011-10-28 Thread patsy
Check the latest post on http://undeadly.org (naddy@'s report)

On Fri, Oct 28, 2011 at 07:41:20PM +0200, Sime Ramov wrote:
 Since OpenBSD libc now supports multi-byte characters, are there any
 forthcoming plans to bring this support to nvi?
 
 There is no editor in base which supports it and I don't want to install
 or use vim.



Re: Performance problems with OpenBSD 4.9 under ESXi 5

2011-10-28 Thread Gene
I was wrong, just changing the guest OS type did not fix my problem.
The morning following this email I found the CPU being pegged again.

I ended up installing the i386 version of 4.9 and used FreeBSD 32-bit
as the guest os type.  These VMs have been running for four days
without a problem.  If it occurs again I'll try the other suggestions
provided here.

-Gene

On Sun, Oct 23, 2011 at 10:09 PM, Gene gh5...@gmail.com wrote:
 This problem appears to be resolved.  By changing the guest os type
 from FreeBSD (64-bit) to Other (64-bit) these vm guests perform
 much better.

 I found out I could easily duplicate the problem with the following
command:

 find / -type f -exec grep -i moo {} \;

 After ten or so minutes dmesg would be flooded with the vmware:
 sending length failed messages.  Looking at the ESXi system
 performance, that vm guest would have its core pegged.

 After changing the guest os type I ran that find repeatedly in a loop
 for 30 minutes, and the problem didn't come back.  I switched back and
 forth between the OS types a couple of times to confirm my findings.
 With the fix in place the CPU utilisation for that vm guest's core did
 not go above 75%.

 Once again, thank you for your help everyone.

 -Gene

 On Sun, Oct 23, 2011 at 12:10 PM, Gene gh5...@gmail.com wrote:
 This is just an update, I've still got to try everything that was
 suggested before.

 This issue is finally occurring again, and I have been able to collect
 more information about it:

 # uptime
 11:46AM  up 3 days, 22:50, 1 user, load averages: 1.33, 1.12, 1.10

 # ps aux
 USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
 root 1  0.0  0.2   364   376 ??  IsWed12PM0:00.09
/sbin/init
 root 17473  0.0  0.3   412   812 ??  IsWed12PM0:00.09
 syslogd: [priv] (syslogd)
 _syslogd  4944  0.0  0.3   420   860 ??  S Wed12PM1:59.70
 syslogd -a /var/www/dev/log -a /var/empty/dev/log
 root 17203  0.0  0.2   572   464 ??  IsWed12PM0:00.01
 pflogd: [priv] (pflogd)
 _pflogd  25836  0.0  0.2   636   384 ??  S Wed12PM1:18.70
 pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
 root 20453  0.0  0.4   496  1020 ??  IsWed12PM0:02.17
 ntpd: [priv] (ntpd)
 _ntp 27033  0.0  0.4   548  1092 ??  S Wed12PM0:36.73
 ntpd: ntp engine (ntpd)
 _ntp 30318  0.0  0.4   676  1008 ??  I Wed12PM0:00.02
 ntpd: dns engine (ntpd)
 root 12410  0.0  0.5   616  1384 ??  IsWed12PM0:00.02
/usr/sbin/sshd
 root 18650  0.0  0.3   412   832 ??  IsWed12PM0:00.06 inetd
 root 13652  0.0  0.4   668   912 ??  IsWed12PM0:04.15 cron
 root 12191  0.0  0.8  1216  2116 ??  SsWed12PM1:36.36
 sendmail: accepting connections (sendmail)
 root 18822  0.0  1.2  3452  3084 ??  Is11:22AM0:00.13
 sshd: gene [priv] (sshd)
 gene 27682  0.3  0.9  3420  2312 ??  S 11:22AM0:00.55
 sshd: gene@ttyp0 (sshd)
 gene 18431  0.0  0.2   616   492 p0  Ss11:22AM0:00.14 -ksh
(ksh)
 root 23079  0.1  0.2   692   536 p0  S 11:46AM0:00.07 -ksh
(ksh)
 root 19366  0.0  0.1   516   328 p0  R+11:47AM0:00.00 ps -aux
 root 17451  0.0  0.3   280   864 C0  Is+   Wed12PM0:00.02
 /usr/libexec/getty std.9600 ttyC0
 root 23962  0.0  0.3   324   864 C1  Is+   Wed12PM0:00.01
 /usr/libexec/getty std.9600 ttyC1
 root  2571  0.0  0.3   272   860 C2  Is+   Wed12PM0:00.01
 /usr/libexec/getty std.9600 ttyC2
 root  9191  0.0  0.3   296   864 C3  Is+   Wed12PM0:00.02
 /usr/libexec/getty std.9600 ttyC3
 root  2812  0.0  0.3   416   868 C5  Is+   Wed12PM0:00.01
 /usr/libexec/getty std.9600 ttyC5

 # vmstat -i
 interrupt   total rate
 irq0/clock   34043772   99
 irq97/mpi0 7720662
 irq112/em0  962370
 Total34912075  102

 # systat
   1 usersLoad 1.10 1.07 1.08 PAUSED   Sun Oct 23 11:46:02
2011

memory totals (in KB)PAGING   SWAPPING
Interrupts
   real   virtual free   in  out   in  out  105
total
 Active12420 12420   185072   ops100
clock
 All   55712 55712   447212   pages4
mpi0
  1 em0
 Proc:r  d  s  wCsw   Trp   Sys   Int   Sof  Flt   forks
   6211788 4   102   21   fkppw
  fksvm
   0.0%Int   0.2%Sys   0.4%Usr   0.0%Nic  99.4%Idle   pwait
 ||||||||||| 2 relck
2 rlkok
  noram
 Namei Sys-cacheProc-cacheNo-cache ndcpy
Calls hits%hits %

(12月1日济南会议)科技项目专项资金申报暨企业知识产权管理战略及专利运用会议通知

2011-10-28 Thread 514019
10:33:07

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of 
=?utf-8?B?5LyB5LqL5Lia5Y2V5L2N56eR5oqA566h55CG5pqo5LiT6aG56LWE6YeR55Sz5oql56CU6K6o5LyaLmRvYw==?=]



El arte de NEGOCIAR en COMPRAS...¡Generador de UTILIDADES!.

2011-10-28 Thread Adriana Batrez
El arte de NEGOCIAR en COMPRAS [IMAGE]El arte de NEGOCIAR en COMPRAS

El arte de NEGOCIAR en COMPRAS...!Importante Generador de UTILIDADES!.

Asista a este exclusivo evento y aprenda el Arte de Negociar en
Compras, identificando los principios, criterios y directrices mas
efectivas para establecer alianzas poderosas que incrementen las
utilidades de su empresa y fortalezcan su red de proveedores confiables.
Entre los temas a tratar se incluyen:

  * Por qui los beneficios hoy dma estan en la Compra mas que en la
venta.

  * Ticnicas para convertir a sus oponentes en aliados.

  * Cuales son los puntos claves en el proceso de negociacisn.

  * Csmo establecer una metodologma de negociacisn eficaz.

  * Ticnicas para seleccionar un equipo de negociacisn triunfador.

  * Aspectos importantes a considerar en negociaciones internacionales.

[IMAGE]

!Reciba en este momento el folleto informativo!
Si le es mas csmodo, responda este correo con los siguientes datos:
Empresa:
Nombre:
Ciudad:
Telifono:

[IMAGE]

[IMAGE]

ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS
POLMTICAS ANTISPAM INTERNACIONALES Y LOCALES: Para modificar las
preferencias de su registro o des suscribirse de estas invitaciones, solo
haga click en la liga que se encuentra en el penzltimo parrafo de este
envmo y automaticamente quedara des suscrito. Para ello debe tener
activadas las funcionalidades de conexisn adecuadas en el sistema de
correo que utilice. Si por alguna razsn no le funciona el vmnculo, solo
responda este correo con el SUBJECT des suscribir y automaticamente
quedara fuera de nuestras listas.
Este correo ha sido enviado a: misc@openbsd.org

Preferencias y Des suscripcisn |   Polmticas de Privacidad

[IMAGE]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
arte_01.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
arte_02.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
arte_03.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
barra.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
obtener.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
qt-septiembre_01.jpg]