<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Lxc on Morfitronik</title>
    <link>https://morfikov.github.io/tags/lxc/</link>
    <description>Recent content in Lxc on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Fri, 30 Oct 2015 17:13:58 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/lxc/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Wine w kontenerze LXC</title>
      <link>https://morfikov.github.io/post/wine-w-kontenerze-lxc/</link>
      <pubDate>Fri, 30 Oct 2015 17:13:58 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/wine-w-kontenerze-lxc/</guid>
      <description>&lt;p&gt;Każdy kto zmienił architekturę systemu z i386 na amd64 raczej nie dostrzegł większej różnicy w
operowaniu na którejś z nich. Czasem jedynie pakiety w nazwie mają 64 zamiast 32. Jest natomiast
jedna rzecz, która drażni chyba każdego. Mowa tutaj o &lt;a href=&#34;https://www.winehq.org/&#34;&gt;projekcie Wine&lt;/a&gt;.
Wine nie umie obsługiwać natywnie serwera dźwięku PulseAudio. Do tego dochodzi jeszcze problem,
który związany jest z tymi wszystkimi pakietami 32 bitowymi, które trzeba zainstalować. I w ten
sposób nasz system staje się bardziej multiarch niż amd64. W tym wpisie postaramy się przy pomocy
kontenera LXC odizolować Wine od całej reszty systemu operacyjnego, tak by nie musieć wgrywać do
niego całej masy zbędnych bibliotek.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Konfiguracja kontenerów LXC</title>
      <link>https://morfikov.github.io/post/konfiguracja-kontenerow-lxc/</link>
      <pubDate>Thu, 29 Oct 2015 23:27:24 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/konfiguracja-kontenerow-lxc/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://wiki.debian.org/LXC&#34;&gt;Kontenery LXC&lt;/a&gt; mają za zadanie odizolować poszczególne usługi od
pozostałej części systemu. LXC jest podobny nieco do maszyn wirtualnych, np. tych tworzonych przez
VirtualBox. Niemniej jednak, oba mechanizmy różnią się trochę. Zasadnicza różnica między nimi polega
na tym, że LXC wykorzystuje &lt;a href=&#34;https://morfikov.github.io/post/przygotowanie-srodowiska-chroot-do-pracy/&#34;&gt;środowisko
chroot&lt;/a&gt; , w którym współdzielone
jest jądro operacyjne. Nie trzeba także z góry określać zasobów pod działanie takiego kontenera, tak
jak to ma w przypadku maszyn wirtualnych. Rzućmy zatem okiem jak wygląda konfiguracja takich
kontenerów na linux&#39;ie.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>TSO, czyli odciążenie segmentacji TCP</title>
      <link>https://morfikov.github.io/post/tso-czyli-odciazenie-segmentacji-tcp/</link>
      <pubDate>Tue, 30 Jun 2015 21:15:08 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/tso-czyli-odciazenie-segmentacji-tcp/</guid>
      <description>&lt;p&gt;Stawiając sobie środowisko testowe pod wireshark&#39;a w celu analizy pakietów sieciowych, zauważyłem,
że coś mi się nie zgadza odnośnie wielkości przesyłanych pakietów między interfejsami kontenerów
LXC. Jakby nie patrzeć, środowisko testowe ma być odwzorowaniem środowiska produkcyjnego i w tym
przypadku wszelkie zasady dotyczące, np. podziału danych na segmenty, muszą być takie same.
Generalnie rzecz biorąc rozmiar pakietu powinien wynosić 1514 bajtów, a był parokrotnie większy.
Okazało się, że jest to za sprawą odciążenia segmentacji w protokole TCP (&lt;a href=&#34;https://lwn.net/Articles/564978/&#34;&gt;TCP Segmentation
Offload&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
