extend docs/nspawn.md

docs/nspawn.md

@@ -2,6 +2,8 @@
 
 [This Link For Arch Linux Wiki for Nspawn Containers](https://wiki.archlinux.org/index.php/Systemd-nspawn)
 
+I like the idea of starting with the easy containers first.
+
 ### Create a FileSystem
 
 ```bash
@@ -24,6 +26,15 @@ At this point you might want to copy over some configs to save time later.
 ```bash
 systemd-nspawn -b -D <container>
 passwd
+# assuming you copied over /etc/locale.gen
+locale-gen
+# set timezone
+timedatectl set-timezone <timezone>
+# enable network time
+timedatectl set-ntp 1
+# enable networking
+systemctl enable systemd-networkd
+systemctl enable systemd-resolved
 poweroff
 # if you want to nat the container add *-n* flag
 systemd-nspawn -b -D <container> -n
@@ -32,6 +43,7 @@ systemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg
 ```
 
 ### Networking
+Here's a link that skips ahead to [Automatically Starting the Container](#automatically-starting-the-container)
 
 On Arch, assuming you have systemd-networkd and systemd-resolved
 set up correctly, networking from the host end of things should
@@ -52,7 +64,7 @@ Kind=bridge
 Name=br0
 
 [Network]
-Address=10.0.55.1/24
+Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste
 DHCPServer=yes
 IPMasquerade=yes
 ```
@@ -70,6 +82,8 @@ systemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/p
 ```
 
 ### Automatically Starting the Container
+Here's a link back up to [Networking](#networking)
+in case you previously skipped ahead.
 
 There are two ways to automate starting the container. You can override
 `systemd-nspawn@.service` or create an *nspawn* file.  
@@ -112,6 +126,9 @@ machinectl shell <container>
 bash
 ```
 
+This would be a good time to check for network and name resolution,
+symlink resolv.conf if need be.
+
 ### Initial Configuration Inside The Container
 
 ```bash
@@ -131,3 +148,21 @@ ping -c 3 google.com
 ```
 
 [If you want to change the locale](https://wiki.archlinux.org/index.php/locale)
+
+## Final Observations
+* You can start/stop nspawn containers with `machinectl` command. 
+* You can start nspawn containers with `systemd-nspawn` command.
+* You can configure the systemd service for a container with @nspawn.service file override
+* Or you can configure an nspawn container with a dot.nspawn file
+
+But in regards to the above list
+I have noticed differences in behaviour,
+in some scenarios, concerning file attributes
+for bind mounts.
+
+Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,
+they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might
+be able to resolve each other if they are all connected to the same bridge interface or nspawn
+network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,
+or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers
+to talk to each other. But I intend to look into this some more.

site/index.html

@@ -174,5 +174,5 @@
 
 <!--
 MkDocs version : 0.16.3
-Build Date UTC : 2017-06-29 16:12:17
+Build Date UTC : 2017-06-29 23:11:25
 -->

site/mkdocs/search_index.json

@@ -142,12 +142,12 @@
         },
         {
             "location": "/nspawn/",
-            "text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir <container>\n# use pacstrap to create a file system\npacstrap -i -c -d <container> base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D <container>\npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file.  \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@<container>.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/<container>.nspawn\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash\n\n\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale",
+            "text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nI like the idea of starting with the easy containers first.\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir <container>\n# use pacstrap to create a file system\npacstrap -i -c -d <container> base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D <container>\npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone <timezone>\n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nHere's a link that skips ahead to \nAutomatically Starting the Container\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nHere's a link back up to \nNetworking\n\nin case you previously skipped ahead.\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file.  \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@<container>.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/<container>.nspawn\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash\n\n\n\n\nThis would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale\n\n\nFinal Observations\n\n\n\n\nYou can start/stop nspawn containers with \nmachinectl\n command. \n\n\nYou can start nspawn containers with \nsystemd-nspawn\n command.\n\n\nYou can configure the systemd service for a container with @nspawn.service file override\n\n\nOr you can configure an nspawn container with a dot.nspawn file\n\n\n\n\nBut in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts.\n\n\nAnother curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.",
             "title": "Nspawn"
         },
         {
             "location": "/nspawn/#nspawn-containers",
-            "text": "This Link For Arch Linux Wiki for Nspawn Containers",
+            "text": "This Link For Arch Linux Wiki for Nspawn Containers  I like the idea of starting with the easy containers first.",
             "title": "Nspawn Containers"
         },
         {
@@ -157,17 +157,17 @@
         },
         {
             "location": "/nspawn/#first-boot-and-create-root-password",
-            "text": "systemd-nspawn -b -D <container>\npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg",
+            "text": "systemd-nspawn -b -D <container>\npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone <timezone>\n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg",
             "title": "First boot and create root password"
         },
         {
             "location": "/nspawn/#networking",
-            "text": "On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.  # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge  # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes  Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the  systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.  # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg",
+            "text": "Here's a link that skips ahead to  Automatically Starting the Container  On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.  # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge  # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes  Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the  systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.  # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg",
             "title": "Networking"
         },
         {
             "location": "/nspawn/#automatically-starting-the-container",
-            "text": "There are two ways to automate starting the container. You can override systemd-nspawn@.service  or create an  nspawn  file.    First enable machines.target  # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service  Edit  /etc/systemd/system/systemd-nspawn@<container>.service  to add the  systemd-nspawn  options\nyou want to the  ExecStart  command.  Or create  /etc/systemd/nspawn/<container>.nspawn  # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0  # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though  # in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash",
+            "text": "Here's a link back up to  Networking \nin case you previously skipped ahead.  There are two ways to automate starting the container. You can override systemd-nspawn@.service  or create an  nspawn  file.    First enable machines.target  # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service  Edit  /etc/systemd/system/systemd-nspawn@<container>.service  to add the  systemd-nspawn  options\nyou want to the  ExecStart  command.  Or create  /etc/systemd/nspawn/<container>.nspawn  # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0  # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though  # in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash  This would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.",
             "title": "Automatically Starting the Container"
         },
         {
@@ -175,6 +175,11 @@
             "text": "# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com  If you want to change the locale",
             "title": "Initial Configuration Inside The Container"
         },
+        {
+            "location": "/nspawn/#final-observations",
+            "text": "You can start/stop nspawn containers with  machinectl  command.   You can start nspawn containers with  systemd-nspawn  command.  You can configure the systemd service for a container with @nspawn.service file override  Or you can configure an nspawn container with a dot.nspawn file   But in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts.  Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.",
+            "title": "Final Observations"
+        },
         {
             "location": "/arch_redis_nspawn/",
             "text": "Quick Dirty Redis Nspawn Container on Arch Linux\n\n\nRefer to the \nNspawn\n page for setting up the nspawn container,\ninstall redis, and start/enable redis.service.\nOnce you have the container running, it seems all you have to do to get\nthings working in a container subnet is to change the bind address.\n\n\n# /etc/redis.conf\n# bind 127.0.0.1\nbind 0.0.0.0\n\n\n\n\nyou can nmap port 6379, be sure to restart redis\n\n\nAgain I would refer you to the Arch Wiki",

site/nspawn/index.html

@@ -76,6 +76,8 @@
         
             <li><a class="toctree-l3" href="#initial-configuration-inside-the-container">Initial Configuration Inside The Container</a></li>
         
+            <li><a class="toctree-l3" href="#final-observations">Final Observations</a></li>
+        
         </ul>
     
 
@@ -126,6 +128,7 @@
               
                 <h1 id="nspawn-containers">Nspawn Containers</h1>
 <p><a href="https://wiki.archlinux.org/index.php/Systemd-nspawn">This Link For Arch Linux Wiki for Nspawn Containers</a></p>
+<p>I like the idea of starting with the easy containers first.</p>
 <h3 id="create-a-filesystem">Create a FileSystem</h3>
 <pre><code class="bash">cd /var/lib/machines
 # create a directory
@@ -143,6 +146,15 @@ pacstrap -i -c -d &lt;container&gt; base --ignore linux
 <h3 id="first-boot-and-create-root-password">First boot and create root password</h3>
 <pre><code class="bash">systemd-nspawn -b -D &lt;container&gt;
 passwd
+# assuming you copied over /etc/locale.gen
+locale-gen
+# set timezone
+timedatectl set-timezone &lt;timezone&gt;
+# enable network time
+timedatectl set-ntp 1
+# enable networking
+systemctl enable systemd-networkd
+systemctl enable systemd-resolved
 poweroff
 # if you want to nat the container add *-n* flag
 systemd-nspawn -b -D &lt;container&gt; -n
@@ -151,6 +163,7 @@ systemd-nspawn -b -D &lt;container&gt; -n --bind=/var/cache/pacman/pkg
 </code></pre>
 
 <h3 id="networking">Networking</h3>
+<p>Here's a link that skips ahead to <a href="#automatically-starting-the-container">Automatically Starting the Container</a></p>
 <p>On Arch, assuming you have systemd-networkd and systemd-resolved
 set up correctly, networking from the host end of things should
 just work.<br />
@@ -167,7 +180,7 @@ Kind=bridge
 Name=br0
 
 [Network]
-Address=10.0.55.1/24
+Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste
 DHCPServer=yes
 IPMasquerade=yes
 </code></pre>
@@ -183,6 +196,8 @@ systemd-nspawn -b -D &lt;container&gt; --network-bridge=br0 --bind=/var/cache/pa
 </code></pre>
 
 <h3 id="automatically-starting-the-container">Automatically Starting the Container</h3>
+<p>Here's a link back up to <a href="#networking">Networking</a>
+in case you previously skipped ahead.</p>
 <p>There are two ways to automate starting the container. You can override
 <code>systemd-nspawn@.service</code> or create an <em>nspawn</em> file.  </p>
 <p>First enable machines.target</p>
@@ -217,6 +232,8 @@ machinectl shell &lt;container&gt;
 bash
 </code></pre>
 
+<p>This would be a good time to check for network and name resolution,
+symlink resolv.conf if need be.</p>
 <h3 id="initial-configuration-inside-the-container">Initial Configuration Inside The Container</h3>
 <pre><code class="bash"># set time zone if you don't want UTC
 timedatectl set-timezone &lt;timezone&gt;
@@ -234,6 +251,23 @@ ping -c 3 google.com
 </code></pre>
 
 <p><a href="https://wiki.archlinux.org/index.php/locale">If you want to change the locale</a></p>
+<h2 id="final-observations">Final Observations</h2>
+<ul>
+<li>You can start/stop nspawn containers with <code>machinectl</code> command. </li>
+<li>You can start nspawn containers with <code>systemd-nspawn</code> command.</li>
+<li>You can configure the systemd service for a container with @nspawn.service file override</li>
+<li>Or you can configure an nspawn container with a dot.nspawn file</li>
+</ul>
+<p>But in regards to the above list
+I have noticed differences in behaviour,
+in some scenarios, concerning file attributes
+for bind mounts.</p>
+<p>Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,
+they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might
+be able to resolve each other if they are all connected to the same bridge interface or nspawn
+network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,
+or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers
+to talk to each other. But I intend to look into this some more.</p>
               
             </div>
           </div>