DOCSLIB.ORG

OS Circular on QEMU/KQEMU/KVM/Xenhvm

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

OS Circular on QEMU/KQEMU/KVM/Xen-HVM http://openlab.jp/oscircular/ Kuniyasu Suzaki, Toshiki Yagi, Kengo Iijima, Nguyen Anh Quynh National Institute of Advanced Industrial Science and Technology (AIST,Japan) ABSTRACT OS Circular is a framework of Internet Disk Image Distributor for virtual machines. The disk images are based on QEMU-DM(device model) and boot on QEMU, KQEMU, KVM and Xen-HVM. They are distributed by the stackable virtual disk "HTTP-FUSE CLOOP". It re-constructs a virtual disk with split and compressed block files on HTTP Servers. The file name of block file is the SHA1 digest of its contents. A block file is checked when it is re-mapped to virtual disk on a client PC. Block files are cached on a local storage and they make possible disconnect operation. Trusted HTTP-FUSE CLOOP is stackable and easy to add news block files for security update. These features enable us to distribute OS images for anonymous users via Internet. 1. Introduction We are developing "OS Circular"[1,2] which boots any OSes on anonymous PC. It makes easy to try new OS features. For this purpose we use virtual machine to get a common PC environment on any PCs. OS Circular is based on "HTTP-FUSE Xenoppix" [3]. HTTP-FUSE Xenoppix offers basic function for Internet Thin Client and enables to boot NetBSD or Plan9. However it is based on para-virtualization of "Xen", which limits Guest OSes and restricts automatic security update of kernel. Furthermore the virtual disk "HTTP-FUSE CLOOP" has no security protection. This paper resolves these problems and offers secure and easy-to-use OS Circulation Environment. FLOZ (Free Live OS Zoo) [4] has similar concept of our OS Circular. It enables us to boot many OSes in the Web browser. FLOZ runs a QEMU virtual machine on the server and users interacts with the Guest OS on the QEMU via a Java-based tight VNC client. It is innovative OS testing environment but the performance and scalability is limited, because it is server centric system and suffers network latency on Internet. Besides the OS on FLOZ doesn©t allow the network connection because of network resource and security restriction on the server. Virtual disk of QEMU and VMware is popular to distribute ready-to-use OS image. However a virtual disk must be treated as one large file because it includes all software. It takes much time to download. Furthermore, a big virtual disk has to re-build when a bit of data is updated. It is not good for urgent security update. Design principle for OS Circular is to utilize existing infrastructure, because it aims global deployment and minimizes maintenance cost. OS Circular is a client centric system, because current client PC has a powerful CPU and network interface and the function of server is limited to file distribution only. We use HTTP for file distribution because Web hosting service is easy-to-get and mirror severs and cache proxies are utilized. The validness of contents is checked by a client PC, which is offered by Trusted HTTP-FUSE CLOOP. HTTP-FUSE CLOOP is stackable virtual disk and enables partial update of virtual disks for application security. OS Circular uses full virtualization because the Guest OSes get automatic security update service. The kernel of Guest OS should be the target of security update. In this paper we describe the detail of OS Circular. In section2 we mention about the virtual machine loader. In section 3 the requirement of virtual disks is described. The detail of Trusted HTTP-FUSE CLOOP is mention in section 4. Current implementation of OS Circular is reported in section 5. We discuss related works and future plans in section 6 and conclude in section 7. 2. Virtual Machine Loader Full virtualization offers an abstraction layer for Guest OSes. The abstraction layer provides a common virtualized PC environment on anonymous PC. There are no restriction for Guest OS. We can install Guest OS with normal installer, update the OS with package management software, and migrate the disk image to other PCs which have the same full virtualization. For this purpose, VMware is used on SoulPad[5] , VAT (Virtual Appliance Transceiver) of Collective[6] , LivePC of Moka5[7] and Internet Suspend/Resume[8]. The drivers for real devices are supported by the host OS. SoulPad and VAT of Collective use KNOPPIX as the host OS, because KNOPPIX has "AutoConfig" function that automatically detects available devices at boot time and loads the appropriate Linux drivers. The combination of AutoConfig and full virtualization on the host OS acts as a virtual machine loader. So we use VMKnoppix[9] for OS Circular. 2.1 VMKnoppix VMKnoppix[9] is a collection of Virtual Machine software on the 1CD Linux "KNOPPIX". KNOPPIX prepares device drivers on any client PC and Full virtualization is offered by Xen-HVM[10], QEMU[11], KEQMU(QEMU Accelerator)[12], and KVM[13]. Xen-HVM and KVM require virtualization instructions (Intel VT or AMD-V) which offer a mode to trap sensitive instructions. VMKnoppix works as a virtual machine loader. 2.2 Unified Device Model Xen-HVM, QEMU, KEQMU, and KVM assumes the same devices which is called QEMU-DM(Device model). They are RealTek RTL8029 for NIC, Cirrus Logic GD5446 for Video Card and etc. The guest OS only have to support these devices. The unified device model enables to boot the disk images on the virtual machines. However the CPU architecture is different among Xen-HVM, QEMU, KEQMU, and KVM. Xen-HVM uses the same architecture of the running real CPU. Fortunately the difference doesn©t cause big problem because the current operating system uses common i386 packages. The packages run on Pentium Pro or after IA32 CPU. 3. Requirements for Virtual Disks This section examines other important features that virtual disks should offer, such as versioning, globalization, and security. The main requirements of virtual disks are described in [14]. According to the requirements we shape the design for Trusted HTTP-FUSE CLOOP presented in the next section. 3.1 Versioning Versioning of virtual disks are desirable feature on virtual machine. Non-persistent versioning is used for "undo" of operations and persistent versioning is used for "rollback" of OS image. The versioning is also important for sharing and customizing virtual disks. Some virtual machine softwares have "undo" function. For example VMware has Non-persistent mode and QEMU and UserModeLinux have CopyOnWrite. Xen uses DeviceMapper of Linux for non-persistent versioning. So Virtual Disks should offer persistent versioning. Trusted HTTP-FUSE CLOOP has same versioning of Venti[15]. Venti is Plan9©s archival storage system that permanently stores data blocks. A SHA1 digest of the data (called score by Venti) acts as the address of the data. This enforces a write-once policy since no other data block can be found with the same address. The addresses of multiple writes of the same data are identical, so duplicate data is easily identified and the data block is stored only once. Data blocks cannot be removed, making it ideal for permanent or backup storage. Unfortunately Venti requires special protocol for file system and limits the scalability. Trusted HTTP-FUSE CLOOP saves data blocks to files and utilizes HTTP to distribute them. 3.2 Globalization Virtual disks are desired to be shared via Internet for OS circulation. It doesn©t mean that virtual disks are downloadable. Virtual disks should be accessed partially when the part is requested. Remote Block Device meets the requirement and there are many choices, for example, iSCSI, AOE(ATA over Ethernet), iFCP, etc. Unfortunately they use special protocols and require special daemons on the server. Most of them are designed for LAN and aren©t good for Internet. Trusted HTTP-FUSE CLOOP re-constructs a virtual disk with the partial block files which are downloadable via HTTP. Disconnect operation is also desired for virtual disks to achieve Mobile Computing. As file systems "AFS" and "Coda" deal with disconnect operation but they require special protocol and daemons for servers. Stateless Linux[16] offers disconnect operation for Thin Client PC. Stateless Linux runs with network storage or snapshot image saved local storage. Block files of Trusted HTTP-FUSE CLOOP are also saved to a local storage and re- usable. When whole block files are saved in a local storage, network connection is not required. 3.3 Security Basically security management is independent of virtual disk. Security of kernel and applications should be managed by security software or package manager. The commitment of virtual disk is to keep uncontaminated contents. Especially the security of network virtual disk is to prevent intrusion. One way to prevent intrusion is to establish secure communication. However secure communication has to assign a fixed server and limits scalability. Trusted HTTP-FUSE CLOOP adapts a validation mechanism on a client. The driver checks the validity of block contents when it mapped to the virtual disk. It allows distributing block data by anonymous servers. 4. Stackable Virtual Disk "Trusted HTTP-FUSE CLOOP" The idea of Trusted HTTP-FUSE CLOOP depends on CLOOP of KNOPPIX. CLOOP is convenient because it saves block device to a file and reduces the size. However a CLOOP file is still big. The size of traditional CD- KNOPPIX is about 700MB. It must be treated as one file and takes much time to download. When a bit of data is updated, a big CLOOP file has to re-build. Furthermore CLOOP has no security protection. To solve the problems, we adapt block management style of Venti[15]. Data of a block device is divided by a fixed block size and saved for many small block files.
Recommended publications
  • HTTP-FUSE Xenoppix

    HTTP-FUSE Xenoppix

    HTTP-FUSE Xenoppix Kuniyasu Suzaki† Toshiki Yagi† Kengo Iijima† Kenji Kitagawa†† Shuichi Tashiro††† National Institute of Advanced Industrial Science and Technology† Alpha Systems Inc.†† Information-Technology Promotion Agency, Japan††† {k.suzaki,yagi-toshiki,k-iijima}@aist.go.jp [email protected], [email protected] Abstract a CD-ROM. Furthermore it requires remaking the entire CD-ROM when a bit of data is up- dated. The other solution is a Virtual Machine We developed “HTTP-FUSE Xenoppix” which which enables us to install many OSes and ap- boots Linux, Plan9, and NetBSD on Virtual plications easily. However, that requires in- Machine Monitor “Xen” with a small bootable stalling virtual machine software. (6.5MB) CD-ROM. The bootable CD-ROM in- cludes boot loader, kernel, and miniroot only We have developed “Xenoppix” [1], which and most part of files are obtained via Internet is a combination of CD/DVD bootable Linux with network loopback device HTTP-FUSE “KNOPPIX” [2] and Virtual Machine Monitor CLOOP. It is made from cloop (Compressed “Xen” [3, 4]. Xenoppix boots Linux (KNOP- Loopback block device) and FUSE (Filesys- PIX) as Host OS and NetBSD or Plan9 as Guest tem USErspace). HTTP-FUSE CLOOP can re- OS with a bootable DVD only. KNOPPIX construct a block device from many small block is advanced in automatic device detection and files of HTTP servers. In this paper we describe driver integration. It prepares the Xen environ- the detail of the implementation and its perfor- ment and Guest OSes don’t need to worry about mance. lack of device drivers.
  • How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise

    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise

    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise Abstract This paper will document a process to create a custom Live CD for secure remote incident handling on Windows and Linux systems. The process will include how to configure SSH for remote access to the Live CD even when running behind a NAT device. The combination of customization and secure remote access will make this process valuable to incident handlers working in enterprise environments with limited remote IT support. Bert Hayes, [email protected] How to Create a Custom Live CD for Remote Incident Handling 2 Table of Contents Abstract ...........................................................................................................................................1 1. Introduction ............................................................................................................................5 2. Making Your Own Customized Debian GNU/Linux Based System........................................7 2.1. The Development Environment ......................................................................................7 2.2. Making Your Dream Incident Handling System...............................................................9 2.3. Hardening the Base Install.............................................................................................11 2.3.1. Managing Root Access with Sudo..........................................................................11 2.4. Randomizing the Handler Password at Boot Time ........................................................12
  • Deep Compression

    Deep Compression

    COVER STORY Cloop DEEPBlock device compression COMPRESSION with the cloop module KYRO, photocase.com KYRO, The cloop module lets you manage compression at the block device 512 bytes), and they are usually used for random access storage like ramdisks, level. Read on to learn how Knoppix and other Live CDs fit all that CD-ROMs, floppy disks, hard disks, and hard disk partitions. software on a single disc. BY KLAUS KNOPPER Filesystems are a logical representa- tion of ordered data that is often present loop is a kernel block device block-based devices. If you look into the on a block device. A filesystem turns raw module used in Live CDs such output of ls -l /dev, you will easily recog- data into the familiar directory/file view. Cas Knoppix. The cloop module nize these devices by the prefix – c for The mount command is the bridge be- allows the system to read compressed character-based and b for block-based tween a block device partition and its data, usually from a file, thus creating devices – at the beginning of the output projection into a mount point directory. compressed virtual disks. Using cloop, line (see Listing 1). a Linux installation of about 2GB fits on Character-based devices, such as tape Cloop: A Compressed a single 700MB CD-R disc. In this article, drives, mice, and gamepads, provide se- Loopback Block Device I look at how cloop works and provide quential, character-by-character access One block device included in any Linux some insight into general kernel struc- to data.
  • QEMU Version 4.2.0 User Documentation I

    QEMU Version 4.2.0 User Documentation I

    QEMU version 4.2.0 User Documentation i Table of Contents 1 Introduction ::::::::::::::::::::::::::::::::::::: 1 1.1 Features :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2 QEMU PC System emulator ::::::::::::::::::: 2 2.1 Introduction :::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.2 Quick Start::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.3 Invocation :::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.3.1 Standard options :::::::::::::::::::::::::::::::::::::::::: 3 2.3.2 Block device options :::::::::::::::::::::::::::::::::::::: 12 2.3.3 USB options:::::::::::::::::::::::::::::::::::::::::::::: 23 2.3.4 Display options ::::::::::::::::::::::::::::::::::::::::::: 23 2.3.5 i386 target only::::::::::::::::::::::::::::::::::::::::::: 30 2.3.6 Network options :::::::::::::::::::::::::::::::::::::::::: 31 2.3.7 Character device options:::::::::::::::::::::::::::::::::: 38 2.3.8 Bluetooth(R) options ::::::::::::::::::::::::::::::::::::: 42 2.3.9 TPM device options :::::::::::::::::::::::::::::::::::::: 43 2.3.10 Linux/Multiboot boot specific ::::::::::::::::::::::::::: 44 2.3.11 Debug/Expert options ::::::::::::::::::::::::::::::::::: 45 2.3.12 Generic object creation :::::::::::::::::::::::::::::::::: 54 2.3.13 Device URL Syntax ::::::::::::::::::::::::::::::::::::: 66 2.4 Keys in the graphical frontends :::::::::::::::::::::::::::::::: 69 2.5 Keys in the character backend multiplexer ::::::::::::::::::::: 69 2.6 QEMU Monitor ::::::::::::::::::::::::::::::::::::::::::::::: 70 2.6.1 Commands :::::::::::::::::::::::::::::::::::::::::::::::
  • Smaller Flight Data Recorders{

    Smaller Flight Data Recorders{

    Available online at http://docs.lib.purdue.edu/jate Journal of Aviation Technology and Engineering 2:2 (2013) 45–55 Smaller Flight Data Recorders{ Yair Wiseman and Alon Barkai Bar-Ilan University Abstract Data captured by flight data recorders are generally stored on the system’s embedded hard disk. A common problem is the lack of storage space on the disk. This lack of space for data storage leads to either a constant effort to reduce the space used by data, or to increased costs due to acquisition of additional space, which is not always possible. File compression can solve the problem, but carries with it the potential drawback of the increased overhead required when writing the data to the disk, putting an excessive load on the system and degrading system performance. The author suggests the use of an efficient compressed file system that both compresses data in real time and ensures that there will be minimal impact on the performance of other tasks. Keywords: flight data recorder, data compression, file system Introduction A flight data recorder is a small line-replaceable computer unit employed in aircraft. Its function is recording pilots’ inputs, electronic inputs, sensor positions and instructions sent to any electronic systems on the aircraft. It is unofficially referred to as a "black box". Flight data recorders are designed to be small and thoroughly fabricated to withstand the influence of high speed impacts and extreme temperatures. A flight data recorder from a commercial aircraft can be seen in Figure 1. State-of-the-art high density flash memory devices have permitted the solid state flight data recorder (SSFDR) to be implemented with much larger memory capacity.
  • Building a Self-Contained Auto-Configuring Linux System On

    Building a Self-Contained Auto-Configuring Linux System On

    Building a self-contained auto-configuring Linux system on an iso9660 filesystem Klaus Knopper [email protected] ¡ http://www.knopper.net/knoppix/ Abstract Bootable CD-Roms with a small Linux rescue system in business card size [1, 2] or regular size live demonstration CDs [3] are becoming popular re- cently. Also, some of the commercial Linux distributors as well as non-profit Open Source groups are developing self-running demos that are preconfigured for certain hardware, or contain a configuration frontend. Knoppix (Knopper’s *nix) is an attempt to not only create a fully featured rescue/demo system on a single CD, but also to unburden the user from the task of hardware identi- fication and configuration of drivers, devices and X11 for his or her specific hardware. The resulting product is supposed to be a platform CD with a stable GNU/Linux base system, that can be used to customize static installations for a specific purpose. Goal: Creating a fully functional and usable Reducing space limitations by compression Linux system running completely from a sin- The core system of about 200 MB (uncompressed) is gle CD currently based on the popular RedHat [4] distribution A frequently asked question asked by people who ”just and contains all basic commands and tools for a generic want to have a glance” on Linux to check out how use- Linux system. That leaves, on a standard 650 MB CD- ful it could be for them is, ”How can I test Linux with- Rom, over 400 MB for custom applications, which can out having to change anything on my computer?”.
  • Building Embedded Linux Systems with Buildroot

    Building Embedded Linux Systems with Buildroot

    Embedded Linux Conference Building embedded Linux systems with Buildroot Thomas Petazzoni Free Electrons http://free-electrons.com/ 1 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Rights to copy © Copyright 2009, Free Electrons [email protected] Document sources, updates and translations: http://free-electrons.com/docs/buildroot Corrections, suggestions, contributions and translations are welcome! Attribution ± ShareAlike 3.0 Latest update: Apr 28, 2009 You are free to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions Attribution. You must give the original author credit. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode 2 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Leveraging free software Thousands of free software packages are available and can be leveraged to build embedded systems With free software You have control over the source Bugs can be fixed New features can be added Your system can be customized In theory, the system designers and developers have a lot of flexibility thanks to free software However, leveraging the existing free software packages may not be very easy.
  • Smaller Flight Data Recorders{

    Smaller Flight Data Recorders{

    Available online at http://docs.lib.purdue.edu/jate Journal of Aviation Technology and Engineering 2:2 (2013) 45–55 Smaller Flight Data Recorders{ Yair Wiseman and Alon Barkai Bar-Ilan University Abstract Data captured by flight data recorders are generally stored on the system’s embedded hard disk. A common problem is the lack of storage space on the disk. This lack of space for data storage leads to either a constant effort to reduce the space used by data, or to increased costs due to acquisition of additional space, which is not always possible. File compression can solve the problem, but carries with it the potential drawback of the increased overhead required when writing the data to the disk, putting an excessive load on the system and degrading system performance. The author suggests the use of an efficient compressed file system that both compresses data in real time and ensures that there will be minimal impact on the performance of other tasks. Keywords: flight data recorder, data compression, file system Introduction A flight data recorder is a small line-replaceable computer unit employed in aircraft. Its function is recording pilots’ inputs, electronic inputs, sensor positions and instructions sent to any electronic systems on the aircraft. It is unofficially referred to as a "black box". Flight data recorders are designed to be small and thoroughly fabricated to withstand the influence of high speed impacts and extreme temperatures. A flight data recorder from a commercial aircraft can be seen in Figure 1. State-of-the-art high density flash memory devices have permitted the solid state flight data recorder (SSFDR) to be implemented with much larger memory capacity.
  • Filesystems in Livecd

    Filesystems in Livecd

    Filesystems in LiveCD J. R. Okajima 2010/12 In the majority of cases, LiveCD uses Squashfs, tmpfs, and AUFS. This report compares usage of squashfs with others to implement LiveCD. Ancient Age A long long time ago, there was an approach to implement LiveCD by “shadow direc- tory”. It may be a rather old name but used very widely. For example, when we have source files under src/, and if we build it under the directory for multiple architec- tures, then we will need to remove all the built files for each build. It is a waste of time. In order to address this problem, make another directory obj/, create symbolic links under it, and build under obj/. This is the shadow directory approach. All the built object files are created under obj/ and the developers do not need to care about the difference of the build directory. LiveCD implemented by this approach (readonly FS + tmpfs + shadow dir) suc- ceeded to redirect the file I/O, eg. read from readonly FS and write to tmpfs, but it brought huge number of symbolic links. Obviously it was not the best approach. Squashfs and AUFS Later LiveCDs adopt a stackable filesystem, eg. Unionfs or AUFS. They both intro- duce a hierarchy to mounting filesystems, and mount a writable filesystem transpar- ently over readonly filesystems, and provide essential features of redirecting file I/O to layers and internal copy-up between layers which enables modification the files on the readonly filesystems logically. Since readonly filesystems can be specified more than one, LiveCD can handle them as an application packages such like compiler package, office suite.
  • O'reilly Knoppix Hacks (2Nd Edition).Pdf

    O'reilly Knoppix Hacks (2Nd Edition).Pdf

    SECOND EDITION KNOPPIX HACKSTM Kyle Rankin Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Knoppix Hacks,™ Second Edition by Kyle Rankin Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Brian Jepson Cover Designer: Karen Montgomery Production Editor: Adam Witwer Interior Designer: David Futato Production Services: Octal Publishing, Inc. Illustrators: Robert Romano and Jessamyn Read Printing History: October 2004: First Edition. November 2007: Second Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Hacks series designations, Knoppix Hacks, the image of a pocket knife, “Hacks 100 Industrial-Strength Tips and Tools,” and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Small print: The technologies discussed in this publication, the limitations on these technologies that technology and content owners seek to impose, and the laws actually limiting the use of these technologies are constantly changing.

  • Proxmox VE Administration Guide Ii

    PROXMOX VE ADMINISTRATION GUIDE RELEASE 7.0 July 6, 2021 Proxmox Server Solutions Gmbh www.proxmox.com Proxmox VE Administration Guide ii Copyright © 2021 Proxmox Server Solutions Gmbh Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Proxmox VE Administration Guide iii Contents 1 Introduction 1 1.1 Central Management....................................... 2 1.2 Flexible Storage......................................... 3 1.3 Integrated Backup and Restore................................. 3 1.4 High Availability Cluster..................................... 3 1.5 Flexible Networking........................................ 4 1.6 Integrated Firewall........................................ 4 1.7 Hyper-converged Infrastructure................................. 4 1.7.1 Benefits of a Hyper-Converged Infrastructure (HCI) with Proxmox VE.......... 4 1.7.2 Hyper-Converged Infrastructure: Storage........................ 5 1.8 Why Open Source........................................ 5 1.9 Your benefits with Proxmox VE.................................. 5 1.10 Getting Help........................................... 6 1.10.1 Proxmox VE Wiki..................................... 6 1.10.2 Community Support Forum................................ 6 1.10.3

  • Secure Boot Cds for VPN HOWTO Secure Boot Cds for VPN HOWTO Table of Contents Secure Boot Cds for VPN HOWTO

    Secure Boot CDs for VPN HOWTO Secure Boot CDs for VPN HOWTO Table of Contents Secure Boot CDs for VPN HOWTO.................................................................................................................1 Jeffery Douglas Waddell jefferydouglaswaddell (at) gmail (dot) com...................................................1 1. Introduction..........................................................................................................................................1 2. Theory..................................................................................................................................................1 3. Technologies........................................................................................................................................1 4. Implementation....................................................................................................................................1 5. Maintenance.........................................................................................................................................1 6. Advanced Issues...................................................................................................................................1 7. Features................................................................................................................................................1 8. Troubleshooting...................................................................................................................................1