samba4 slow startup, shared libs?

2015-06-05 Thread Stuart Henderson
net/samba4 is in the ports tree but not currently enabled in the build,
we're still only using samba 3.x for various reasons, but unfortunately
samba 3 is getting decreasingly useful as more Windows setups move to
newer versions.

One of the issues is that startup of samba4 on OpenBSD is very slow
indeed, seemingly before control is transferred to the program. From
the LD_DEBUG output with timestamps (using the very handy ts(1) from
moreutils):

# LD_DEBUG=1 smbd -D 21 | ts %.s
..snip..
1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1'
1433498513.546323 loading: libnettle.so.1.2 required by 
/usr/local/lib/libhogweed.so.1.1
1433498513.546339 loading: libgmp.so.9.0 required by 
/usr/local/lib/libhogweed.so.1.1
1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of 
/usr/local/lib/libhogweed.so.1.1
1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of 
/usr/local/lib/libhogweed.so.1.1
1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0'
1433498584.125659  flags /usr/libexec/ld.so = 0x0
1433498584.125783 obj /usr/libexec/ld.so has smbd as head
1433498584.149165 relocation took 0.023504
1433498584.149215   StartEnd  Type Open Ref GrpRef 
Name
1433498584.149249   04bec650 04bec691 exe  10   0  
smbd
1433498584.149272   04c19b74e000 04c19bb6 rlib 0107   0 
 /usr/lib/libpthread.so.19.0
1433498584.149293   04c18f3df000 04c18f812000 rlib 075   0  
/usr/local/lib/libsamba-util.so.0.0
..snip..

- a 74 second delay after examining: '/usr/local/lib/libgmp.so.9.0'.
Does anyone have suggestions for finding out what's going on here?
Full text snipped from the above is at http://junkpile.org/samba4-lddebug.txt

The simpler programs in samba4 are also slower than expected to startup
(smbclient --version takes 3-4 seconds) but I haven't identified others which
are quite as bad as smbd yet.



Re: samba4 slow startup, shared libs?

2015-06-05 Thread Mark Kettenis
 Date: Fri, 5 Jun 2015 11:15:38 +0100
 From: Stuart Henderson st...@openbsd.org
 
 net/samba4 is in the ports tree but not currently enabled in the build,
 we're still only using samba 3.x for various reasons, but unfortunately
 samba 3 is getting decreasingly useful as more Windows setups move to
 newer versions.
 
 One of the issues is that startup of samba4 on OpenBSD is very slow
 indeed, seemingly before control is transferred to the program. From
 the LD_DEBUG output with timestamps (using the very handy ts(1) from
 moreutils):
 
 # LD_DEBUG=1 smbd -D 21 | ts %.s
 ..snip..
 1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1'
 1433498513.546323 loading: libnettle.so.1.2 required by 
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546339 loading: libgmp.so.9.0 required by 
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of 
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of 
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0'
 1433498584.125659  flags /usr/libexec/ld.so = 0x0
 1433498584.125783 obj /usr/libexec/ld.so has smbd as head
 1433498584.149165 relocation took 0.023504
 1433498584.149215   StartEnd  Type Open Ref 
 GrpRef Name
 1433498584.149249   04bec650 04bec691 exe  10   0 
  smbd
 1433498584.149272   04c19b74e000 04c19bb6 rlib 0107   0   
/usr/lib/libpthread.so.19.0
 1433498584.149293   04c18f3df000 04c18f812000 rlib 075   0
   /usr/local/lib/libsamba-util.so.0.0
 ..snip..
 
 - a 74 second delay after examining: '/usr/local/lib/libgmp.so.9.0'.
 Does anyone have suggestions for finding out what's going on here?
 Full text snipped from the above is at http://junkpile.org/samba4-lddebug.txt

My first guess would have been that it is spending a lot of time on
initial relocations.  But the line:

  1433498584.149165 relocation took 0.023504

pretty much rules that out.  My suggestion would be to add a few more
DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just
after the _dl_load_dep_libs() call in that function and try to narrow
it down.



Re: [PATCH] FTP as an install method is no more

2015-06-05 Thread Nick Holland
On 06/05/15 01:15, Raf Czlonka wrote:
 Hi all,
 
 I think I got the most obvious ones but there might still be other ones
 scattered among the web pages.
 
 I'm not entirely sure how does that leave the exact wording of
 'ftp.html' in terms of Download via HTTP/FTP, etc. vs. Install via
 ... so I left it unchanged for now.

yeah, there are a few other things to look at on that one, AND ftp.html
is a generated file, so I haven't committed this yet (a little more than
I can do before running off to work in the morning!).  faq1.html and
faq4.html, though, I've committed.

 There's also the text version of the FAQ ('faq/obsd-faq.txt') which I
 haven't updated as it seems to be generated from the HTML version so
 that needs to be done separately - it doesn't seem like this has been
 done for 5.7 release at all as there's an answer to What's new in
 OpenBSD 5.6? section with 5.6 changes (not just the actual question
 like below in the faq1.html).

regenerated and committed, thanks!

Nick.


 
 Regards,
 
 Raf
 
 Index: ftp.html
 ===
 RCS file: /cvs/www/ftp.html,v
 retrieving revision 1.669
 diff -u -p -r1.669 ftp.html
 --- ftp.html  11 May 2015 11:19:50 -  1.669
 +++ ftp.html  5 Jun 2015 05:04:11 -
 @@ -64,7 +64,7 @@ upgrade your system very quickly.
  h3font color=#e0a name=mirrorsDownload via
HTTP/FTP/a/font/h3
  
 -OpenBSD can be also easily installed via HTTP or FTP.
 +OpenBSD can also be easily installed via HTTP.
  Typically you need a single small piece of boot media (e.g., a boot floppy)
  and then the rest of the files can be installed from a number of locations,
  including directly off the Internet.
 Index: faq/faq1.html
 ===
 RCS file: /cvs/www/faq/faq1.html,v
 retrieving revision 1.147
 diff -u -p -r1.147 faq1.html
 --- faq/faq1.html 25 May 2015 15:32:00 -  1.147
 +++ faq/faq1.html 5 Jun 2015 05:04:11 -
 @@ -36,7 +36,7 @@ please, use a max of 72 chars per line -
  lia href=#WhoMaintains1.6 - Who maintains OpenBSD?/a
  lia href=#Next1.7 - When is the next release of OpenBSD?/a
  lia href=#Included1.8 - What is included with OpenBSD?/a
 -lia href=#WhatsNew1.9 - What is new in OpenBSD 5.6?/a
 +lia href=#WhatsNew1.9 - What is new in OpenBSD 5.7?/a
  lia href=#Desktop1.10 - Can I use OpenBSD as a desktop system?/a
  lia href=#HowAbout1.11 - Why is/isn't iProductX/i included?/a
  /ul
 Index: faq/faq4.html
 ===
 RCS file: /cvs/www/faq/faq4.html,v
 retrieving revision 1.355
 diff -u -p -r1.355 faq4.html
 --- faq/faq4.html 25 May 2015 15:32:00 -  1.355
 +++ faq/faq4.html 5 Jun 2015 05:04:11 -
 @@ -235,7 +235,7 @@ You will want to know the following item
liIf ISA, you also need to know hardware settings, and confirm
they are as OpenBSD requires.
/ul
 -liInstall method to be used (CD-ROM, FTP, etc.).
 +liInstall method to be used (CD-ROM, HTTP, etc.).
  liShould an important bug be found, how will the system be patched?
ul
liIf done locally, you will need to have
 @@ -1079,7 +1079,7 @@ Note that on slow hardware, the Get/Ver
Installing xshare57.tgz 100% |**|  4413 KB00:05
Installing xfont57.tgz  100% |**| 38994 KB00:10
Installing xserv57.tgz  100% |**| 18469 KB00:06
 -  Location of sets? (cd disk ftp http or 'done') [done] biEnter/i/b
 +  Location of sets? (cd disk http or 'done') [done] biEnter/i/b
  /pre/td/tr/table
  
  p
 @@ -3005,7 +3005,7 @@ Note: if you will be doing your install 
  need to add your ttsite*.tgz/tt file(s) to the file
  ttindex.txt/tt in the source directory in order for them to be
  listed as an option at install time.
 -This is not needed for FTP or other installs.
 +This is not needed for other install methods.
  
  p
  a name=Multiple/a
 



Pflow export every X seconds

2015-06-05 Thread BARDOU Pierre
Hello,

I'd love to see the feature Joerg Goltermann developed a while ago committed in 
the standard pflow :
http://marc.info/?l=openbsd-miscm=124661838923498w=2

Do you know why it was never committed ? What would it need to be ?
May I help in any way ?


--
Cordialement,


Pierre Bardou
Ingénieur réseau

12, rue Michel Labrousse
CS 93668 - 31036 Toulouse cedex 1


Avant d'imprimer cet e-mail, pensons à l'environnement





Re: RTF_LOCAL and permanent ARP

2015-06-05 Thread Claudio Jeker
On Thu, Jun 04, 2015 at 12:19:10PM +0200, Martin Pieuchot wrote:
 I'd like to put the link-layer address back into the gateway field of
 RTF_LOCAL addresses.  The problem is that RTF_LOCAL routes are also
 marked as RTF_LLINFO and a lot of code assume (correctly) that such
 routes contain valid ARP or ND information.
 
 I believe we decided to use an ``empty'' lladdr because previously all
 the routes created via rt_ifa_add(9) were using the same code and we
 needed the exact same gateway to remove MPATH routes.  But now that
 only RTF_LOCAL routes use this code and taking into consideration that
 such route *cannot* be MPATH, we can simply use ifp-if_sadl instead
 of a blank sockaddr_dl.
 
 This should also fix the (imcomplete) output in arp(8) and ndp(8).
 
 Ok?

If I see this correctly rt_ifa_del is now doing deletes without a gateway
specified for the RTF_LLINFO flag is set. Are you sure that there will be
never multipath routes in that case?

Also do we need to set RTAX_LABEL on remove? I think that is not needed.
This is unrelated and should be handled independently.

Apart from that OK claudio@

 
 Index: net/route.c
 ===
 RCS file: /cvs/src/sys/net/route.c,v
 retrieving revision 1.212
 diff -u -p -r1.212 route.c
 --- net/route.c   26 May 2015 12:19:51 -  1.212
 +++ net/route.c   4 Jun 2015 10:03:51 -
 @@ -1121,27 +1121,23 @@ rt_maskedcopy(struct sockaddr *src, stru
  int
  rt_ifa_add(struct ifaddr *ifa, int flags, struct sockaddr *dst)
  {
 + struct ifnet*ifp = ifa-ifa_ifp;
   struct rtentry  *rt, *nrt = NULL;
   struct sockaddr_rtlabel  sa_rl;
 - struct sockaddr_dl   sa_dl = { sizeof(sa_dl), AF_LINK };
   struct rt_addrinfo   info;
 - u_short  rtableid = ifa-ifa_ifp-if_rdomain;
 - u_int8_t prio = ifa-ifa_ifp-if_priority + RTP_STATIC;
 + u_short  rtableid = ifp-if_rdomain;
 + u_int8_t prio = ifp-if_priority + RTP_STATIC;
   int  error;
  
 - sa_dl.sdl_type = ifa-ifa_ifp-if_type;
 - sa_dl.sdl_index = ifa-ifa_ifp-if_index;
 -
   memset(info, 0, sizeof(info));
   info.rti_ifa = ifa;
   info.rti_flags = flags | RTF_MPATH;
   info.rti_info[RTAX_DST] = dst;
   if (flags  RTF_LLINFO)
 - info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)sa_dl;
 + info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)ifp-if_sadl;
   else
   info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
 - info.rti_info[RTAX_LABEL] =
 - rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);
 + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp-if_rtlabelid, sa_rl);
  
  #ifdef MPLS
   if ((flags  RTF_MPLS) == RTF_MPLS) {
 @@ -1189,14 +1185,14 @@ rt_ifa_add(struct ifaddr *ifa, int flags
  int
  rt_ifa_del(struct ifaddr *ifa, int flags, struct sockaddr *dst)
  {
 + struct ifnet*ifp = ifa-ifa_ifp;
   struct rtentry  *rt, *nrt = NULL;
   struct mbuf *m = NULL;
   struct sockaddr *deldst;
   struct rt_addrinfo   info;
   struct sockaddr_rtlabel  sa_rl;
 - struct sockaddr_dl   sa_dl = { sizeof(sa_dl), AF_LINK };
 - u_short  rtableid = ifa-ifa_ifp-if_rdomain;
 - u_int8_t prio = ifa-ifa_ifp-if_priority + RTP_STATIC;
 + u_short  rtableid = ifp-if_rdomain;
 + u_int8_t prio = ifp-if_priority + RTP_STATIC;
   int  error;
  
  #ifdef MPLS
 @@ -1227,19 +1223,13 @@ rt_ifa_del(struct ifaddr *ifa, int flags
   }
   }
  
 - sa_dl.sdl_type = ifa-ifa_ifp-if_type;
 - sa_dl.sdl_index = ifa-ifa_ifp-if_index;
 -
   memset(info, 0, sizeof(info));
   info.rti_ifa = ifa;
   info.rti_flags = flags;
   info.rti_info[RTAX_DST] = dst;
 - if (flags  RTF_LLINFO)
 - info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)sa_dl;
 - else
 + if ((flags  RTF_LLINFO) == 0)
   info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
 - info.rti_info[RTAX_LABEL] =
 - rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);
 + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp-if_rtlabelid, sa_rl);
  
   if ((flags  RTF_HOST) == 0)
   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
 Index: netinet6/nd6.c
 ===
 RCS file: /cvs/src/sys/netinet6/nd6.c,v
 retrieving revision 1.136
 diff -u -p -r1.136 nd6.c
 --- netinet6/nd6.c15 May 2015 12:00:57 -  1.136
 +++ netinet6/nd6.c4 Jun 2015 09:51:54 -
 @@ -651,7 +651,6 @@ nd6_lookup(struct in6_addr *addr6, int c
   }
   if (!rt) {
   if (create  ifp) {
 - struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK };
   struct rt_addrinfo info;

Re: samba4 slow startup, shared libs?

2015-06-05 Thread Kirill Bychkov
On Fri, June 5, 2015 14:27, Mark Kettenis wrote:
 Date: Fri, 5 Jun 2015 11:15:38 +0100
 From: Stuart Henderson st...@openbsd.org

 net/samba4 is in the ports tree but not currently enabled in the build,
 we're still only using samba 3.x for various reasons, but unfortunately
 samba 3 is getting decreasingly useful as more Windows setups move to
 newer versions.

 One of the issues is that startup of samba4 on OpenBSD is very slow
 indeed, seemingly before control is transferred to the program. From
 the LD_DEBUG output with timestamps (using the very handy ts(1) from
 moreutils):

 # LD_DEBUG=1 smbd -D 21 | ts %.s
 ..snip..
 1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1'
 1433498513.546323 loading: libnettle.so.1.2 required by
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546339 loading: libgmp.so.9.0 required by
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of
 /usr/local/lib/libhogweed.so.1.1
 1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0'
 1433498584.125659  flags /usr/libexec/ld.so = 0x0
 1433498584.125783 obj /usr/libexec/ld.so has smbd as head
 1433498584.149165 relocation took 0.023504
 1433498584.149215   StartEnd  Type Open Ref
 GrpRef Name
 1433498584.149249   04bec650 04bec691 exe  10   0
   smbd
 1433498584.149272   04c19b74e000 04c19bb6 rlib 0107   0
 /usr/lib/libpthread.so.19.0
 1433498584.149293   04c18f3df000 04c18f812000 rlib 075   0
/usr/local/lib/libsamba-util.so.0.0
 ..snip..

 - a 74 second delay after examining: '/usr/local/lib/libgmp.so.9.0'.
 Does anyone have suggestions for finding out what's going on here?
 Full text snipped from the above is at
 http://junkpile.org/samba4-lddebug.txt

 My first guess would have been that it is spending a lot of time on
 initial relocations.  But the line:

   1433498584.149165 relocation took 0.023504

 pretty much rules that out.  My suggestion would be to add a few more
 DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just
 after the _dl_load_dep_libs() call in that function and try to narrow
 it down.


Vadim made an attempt to improve things. May be this can share some light.
http://marc.info/?l=openbsd-portsm=140051145330799w=2
http://marc.info/?l=openbsd-portsm=140078438824316w=2
I've searched old mails and found that 4.0.3 was starting with normal speed. I
have ldd output for 4.0.3 and 4.0.17 to compare.




LibreSSL 2.2 fails to connect to webdav.yandex.com

2015-06-05 Thread 1edhaz+9sj4olxjt6rag
Hello,

LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com.

OpenSSL 1.0.1m from OpenBSD packages does succeed.

Yandex is the largest search engine in Russia. The webdav.yandex.com
site is for accessing their file-hosting service.

System info:

$ uname -a
OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64
$ dmesg | head -n 1 
  
OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun  3 12:09:31 MDT 2015

OpenSSL run:

$ eopenssl version  
OpenSSL 1.0.1m 19 Mar 2015
$ echo -n | eopenssl s_client -debug -connect webdav.yandex.com:443
depth=1 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification 
Authority, CN = Certum Level IV CA
verify error:num=20:unable to get local issuer certificate
verify return:0
CONNECTED(0003)
write to 0xd6b51dc680 [0xd70e4f3000] (297 bytes = 297 (0x129))
 - 16 03 01 01 24 01 00 01-20 03 03 8f 0d ed 87 39   $... ..9
0010 - 96 b6 31 ce a4 4a 01 e9-25 3a 03 96 75 54 60 d0   ..1..J..%:..uT`.
0020 - b9 9b 41 7a d1 af 6f 34-e7 bc 19 00 00 8a c0 30   ..Az..o4...0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b   .,.(.$.k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a   .j.9.8.2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f   =.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67   .+.'.#.g
0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31   .@.3.2.E.D.1
0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f   .-.).%/
0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05   ...A
00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a   
00b0 - 00 15 00 12 00 09 00 ff-01 00 00 6d 00 0b 00 04   ...m
00c0 - 03 00 01 02 00 0a 00 34-00 32 00 0e 00 0d 00 19   ...4.2..
00d0 - 00 0b 00 0c 00 18 00 09-00 0a 00 16 00 17 00 08   
00e0 - 00 06 00 07 00 14 00 15-00 04 00 05 00 12 00 13   
00f0 - 00 01 00 02 00 03 00 0f-00 10 00 11 00 23 00 00   .#..
0100 - 00 0d 00 20 00 1e 06 01-06 02 06 03 05 01 05 02   ... 
0110 - 05 03 04 01 04 02 04 03-03 01 03 02 03 03 02 01   
0120 - 02 02 02 03 00 0f 00 01-01.
read from 0xd6b51dc680 [0xd675564000] (7 bytes = 7 (0x7))
 - 16 03 03 00 57 02 W.
0007 - SPACES/NULS
read from 0xd6b51dc680 [0xd67556400a] (85 bytes = 85 (0x55))
 - 00 53 03 03 55 72 4e 4e-f4 4b 58 3b 97 76 3a c0   .S..UrNN.KX;.v:.
0010 - 3a 70 e1 1e 7b d3 f7 51-39 c4 08 92 8b b0 d9 53   :p..{..Q9..S
0020 - 81 e4 b4 d8 20 0e 38 87-11 8b 29 e5 c3 05 e1 1f    .8...).
0030 - 5b 5b 6f f6 a7 92 70 a5-ec 7c 28 80 ae 6b ba b0   [[o...p..|(..k..
0040 - 6b 90 d5 b9 06 c0 14 00-00 0b 00 0b 00 02 01 00   k...
0050 - ff 01 00 01   
0055 - SPACES/NULS
read from 0xd6b51dc680 [0xd675564003] (5 bytes = 5 (0x5))
 - 16 03 03 0a be.
read from 0xd6b51dc680 [0xd675564008] (2750 bytes = 1393 (0x571))
 - 0b 00 0a ba 00 0a b7 00-06 78 30 82 06 74 30 82   .x0..t0.
0010 - 05 5c a0 03 02 01 02 02-10 69 d8 9e b2 4a ed e3   .\...i...J..
0020 - 01 8b dd 5e ae 9e d0 11-ea 30 0d 06 09 2a 86 48   ...^.0...*.H
0030 - 86 f7 0d 01 01 05 05 00-30 77 31 0b 30 09 06 03   0w1.0...
0040 - 55 04 06 13 02 50 4c 31-22 30 20 06 03 55 04 0a   UPL10 ..U..
0050 - 13 19 55 6e 69 7a 65 74-6f 20 54 65 63 68 6e 6f   ..Unizeto Techno
0060 - 6c 6f 67 69 65 73 20 53-2e 41 2e 31 27 30 25 06   logies S.A.1'0%.
0070 - 03 55 04 0b 13 1e 43 65-72 74 75 6d 20 43 65 72   .UCertum Cer
0080 - 74 69 66 69 63 61 74 69-6f 6e 20 41 75 74 68 6f   tification Autho
0090 - 72 69 74 79 31 1b 30 19-06 03 55 04 03 13 12 43   rity1.0...UC
00a0 - 65 72 74 75 6d 20 4c 65-76 65 6c 20 49 56 20 43   ertum Level IV C
00b0 - 41 30 1e 17 0d 31 34 31-31 31 37 31 32 31 34 31   A0...14111712141
00c0 - 39 5a 17 0d 31 35 31 32-33 31 31 32 31 34 31 39   9Z..151231121419
00d0 - 5a 30 81 9c 31 0b 30 09-06 03 55 04 06 13 02 52   Z0..1.0...UR
00e0 - 55 31 13 30 11 06 03 55-04 0a 0c 0a 59 61 6e 64   U1.0...UYand
00f0 - 65 78 20 4c 4c 43 31 0c-30 0a 06 03 55 04 0b 0c   ex LLC1.0...U...
0100 - 03 49 54 4f 31 0f 30 0d-06 03 55 04 07 0c 06 4d   .ITO1.0...UM
0110 - 6f 73 63 6f 77 31 1b 30-19 06 03 55 04 08 0c 12   oscow1.0...U
0120 - 52 75 73 73 69 61 6e 20-46 65 64 65 72 61 74 69   Russian Federati
0130 - 6f 6e 31 19 30 17 06 03-55 04 03 0c 10 77 65 62   on1.0...Uweb
0140 - 64 61 76 2e 79 61 6e 64-65 78 2e 72 75 31 21 30   dav.yandex.ru1!0
0150 - 1f 06 09 2a 86 48 86 f7-0d 01 09 01 16 12 70 6b   ...*.Hpk
0160 - 69 40 79 61 6e 64 65 78-2d 74 65 61 6d 2e 72 75   i...@yandex-team.ru
0170 - 30 82 01 22 30 0d 06 09-2a 86 48 86 f7 0d 01 01   0..0...*.H.
0180 - 01 05 00 03 82 01 0f 00-30 82 01 0a 02 82 01 01