DOCSLIB.ORG

Das Fedora Projekt

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Das Fedora Projekt Das Fedora Projekt quo vadis Red Hat Enrico Scholz Unix-Stammtisch 28. Oktober 2003 Inhalt Begriffe Red Hat Linux fedora.us Paketfluss Der Zusammenschluss Das Fedora Project Core + Extras + ... Paketmanagement Zeitplan Mitwirkungsmöglichkeiten Begriffe (1) Red Hat (RH) Unternehmensbezeichnung Red Hat Linux (RHL) Linuxdistribution abgelöst durch Produkte des Fedora Projects Red Hat Enterprise Linux (RHEL) Linuxdistribution für Unternehmenseinsatz Ausprägungen für unterschiedliche Zielgruppen: WS, Professional WS, ES, AS Fedora Kopfbedeckung Verwendet in RH Logo ("shadow man") Begriffe (2) Fedora Linux (fedora.us) von Red Hat unabhängiger Anbieter von RPMS Ziel: hochqualitative und aktuelle Pakete Fedora Project von Red Hat gesponsert, von der "Community" unterstützt Ziele: freies Betriebssystem Übernahme entwickelter Technologien in RHEL Produkte Fedora Core, Fedora Legacy, Fedora Extras... Produkte des Fedora Projects Begriffe (3) Paketqualität Maßstab, inwieweit die Zielsetzung nach minimalen, aber umfassenden Abhängigkeiten funktionierenden Updatepfaden gutmütigem Verhalten in abweichenden Umgebungen Standardkonformität (FHS, LSB, freedesktop) leichter Konfigurierbarkeit der installierten Daten guter Wartbarkeit des .spec-Files/der Patches vom Paket erfüllt wird Paket/RPM Verpackungseinheit für Software gebaut aus src.rpm, bestehend aus .spec-Datei Quellen Patches Red Hat Linux (1) Erstveröffentlichung: 31.Oktober 1994, v0.9 "Halloween" Version 1.0 "Mother’s Day" im Mai 1995 Details: http://fedora.redhat.com/about/history/ relativ offen (ISOs, öffentlicher Bugzilla, rawhide) vollständig GPL mp3-Player: nur gegen Lizenzgebühr ($60.000) auslieferbar -> Verlust des GPL Status von RHL ca. 6 monatliche Releasezyklen ausgedehnte Betatests Probleme: stetig wachsende Anzahl potentieller Pakete begrenzte Ressourcen (Entwickler) Sitz von Red Hat in USA: Softwarepatente und DMCA Red Hat ist AG -> keine Experimente mit Legalität Boxen-Verkauf lohnt sich wirtschaftlich nicht Red Hat Linux (2) Auswege aus Paketarmut: Red Hat "contrib" oft bescheidene Qualität Pakete nicht vertrauenswürdig keine Infrastruktur: einfach nur Upload Powertools loose, nicht besonders gepflegte Extra-CD zu rufschädigend und ressourcenbindend -> Wegfall mit RHL 7.2 rhcontrib.bero.org Mitte 2001 vom damaligen RH Entwickler Bernhard Rosenkränzer ins Leben gerufen Ziel: besseres Red Hat "contrib" Aber: kein Sicherheitskonzept, keine offizielle Unterstützung seitens RH Anfang 2002 aufgegeben Red Hat Linux (3) Auswege aus Paketarmut: 3rd Party Repositories freshrpms.net (Matthias Saou), atrpms.physik.fu-berlin.de (Axel Thimm), dag.wieers.com (Dag Wieers) wegen DMCA meist in der freien Welt Ein-Mann-Paketfabriken nicht offen für andere Anbieter schnell & flexibel, aber nur inoffizielle Standards und interne QA fedora.us (1) gegründet im November/Dezember 2002 von Warren Togami (Informatikstudent an Universität von Hawaii) Ziel: 3rd party repository mit Fokus auf Qualität und Sicherheit offizielle Richtlinien offen für jedermann erste vier Monate: Diskussion über Regeln für Paket-Namen: Koexistenz mit RHL Paketen -> RHL Paket hat stets Vorrang Updatepfad unter Vermeidung von Epoch-Erhöhung Spezialfall alphanumerische/CVS Versionierung kurz und einfach Ergebnis: %name-%version-0.fdr.0.%alphatag.%releasetag z.B. "aalib-1.4.0-0.fdr.0.8.rc5.rh90" für aalib-1.4.0rc5 Details: http://www.fedora.us/wiki/PackageNamingGuidelines fedora.us (2) unbequeme Entscheidungen Explizites "Epoch: 0" und Epoch-Tag in versionierten Abhängigkeiten z.B. "Requires: gtk2 >= 0:2.2" Abschreckung von Autoren anderer Repositories Probleme: Hawaii ist US Bundesstaat Theoretisch: separate und eigenständige "freeworld" Server mit minimalen Paketsets Erfüllung von Abhängigkeiten durch Dummy-Libraries im Hauptrepository (z.B. libdvdcss fake) Praktisch: Ignorieren des Problems (bis zum Zusammenschluß mit RH) Versuche für Logo gescheitert: http://people.auc.ca/tack/files/fedora-logo.png ;) fedora.us (3) Kommunikation Bugzilla (https://bugzilla.fedora.us) Mailinglisten IRC (#fedora auf freenode.net) Wiki (http://www.fedora.us/wiki/) fedora.us Paketfluss (1) Erstveröf− fentlichung Annonciert durch Bugzilla Fehlerreport GPG signiertes Paket Bereitstellung im WWW-/FTP-Space des Autors fedora.us Paketfluss (2) Erstveröf− fentlichung QA Sicherheitschecks: Vergleich mit Upstream-Quellen Überprüfung eventueller Patches GPG-Signatur des Paketes Allgemeine Überprüfung des .spec-Files Funktionalitätstest rpmlint Details: http://www.fedora.us/wiki/QAChecklist fedora.us Paketfluss (3) Erstveröf− fentlichung Korrektur QA Wieder: GPG signiertes Paket Bereitstellung in Web-/FTP-Space des Autors fedora.us Paketfluss (4) Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) GPG-signiertes OK von zwei QA-Testern Ziel: automatisierter Build anvisiertes Werkzeug: "mach" (http://thomas.apestaart.org/projects/mach) in vserver-Umgebung (http://linux-vserver.org) tatsächlich: nur manueller Build in vserver fedora.us Paketfluss (5) Verifikation durch Autor Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (6) Repository Verifikation durch Autor Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (7) Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (8) Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) Vorteile: nur "gute" Pakete werden veröffentlicht paranoide Sicherheitsvorkehrungen fedora.us Paketfluss (9) Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) Nachteile: sehr langsam, da wenig Tester (QA) keine Tester bei komplexen Paketen nur weiteres 3rd party repository -> nicht besonders attraktiv für weitere Freiwillige fehlende Infrastruktur Bugzilla nicht wirklich geeignet für Abbildung des QA-Vorgangs Status des Paketes in Bugzilla nicht ersichtlich -> Abschreckung potentieller Tester Build manuell ausgeführt -> hoher Zeitaufwand für Buildmaster RH + fedora.us Zusammenschluss (1) Red Hat: RHL wirtschaftlich nicht rentabel limitierte Ressourcen, viel Potential wegen hoher Bekanntheit Aufgabe von RHL im Juli 2003 Ziel: stärkere Einbeziehung der "Community" (Debian Modell) Aber: nur unklares Konzept über das "Wie" fedora.us: limitierte Ressourcen funktionierender Prozess & Policies RH + fedora.us Zusammenschluss (2) Zusammenschluss am 22.September 2003 durch Warren Togami initiiert "fedora" nun Warenzeichen von Red Hat http://fedora.us für Übergangszeit weiterhin aktiv Entfernung rechtlich kritischer Pakete: betroffen: 70 von 287 z.B. MPEG Software, CSS, Spiele-Nachbauten, valgrind Fedora-Freeworld momentan http://rpm.livna.org (Damien Nade, "Anvil") Ziel: Nachbau der alten Infrastruktur & Verwendung neuer Elemente noch kein Name, "fedora XXX" nicht verwendbar eventuell Zusammenschluss mit Penguin Liberation Front (http://plf.zarb.org)?? Das Fedora Project viele Details unklar Red Hat bietet Infrastruktur (CVS, Build-Maschinen, Bugzilla, Bandbreite, Mailinglisten, ...) und Entwickler Resultate fließen in RHEL Produkte keine Geheimnisse Steuerungskomitee http://fedora.redhat.com/about/leadership.html hauptsächlich RH Mitarbeiter Aufteilung der Pakete in Fedora Core Fedora Extras Fedora Alternatives Fedora Legacy Fedora Core Nachfolger von Red Hat Linux ISO Images von Fremdanbietern unter diesem Namen kommerziell verwertbar -> deshalb eigenständiger "Fedora(tm)" Name blee^Wleading edge 4-6 monatige Releaseintervalle Updates 2-3 Monate nach nächstem Release keinerlei Support keinerlei Hardwarezertifikate RHEL-Abgrenzung: http://fedora.redhat.com/about/rhel.html Fedora Extras + Alternatives Fedora Extras Ergänzung von Fedora Core Aufteilung in themenbezogene Repositories, z.B. "Fedora Extras HPC" für High-Performance Computing Fedora Alternatives Ersatz von Fedora Core Paketen Details: http://fedora.redhat.com/participate/terminology.html Fedora Legacy Basis Idee + Organisation: Jesse Keating ("ender") Pflege existierender Red Hat Linux (7.3 & 9) und bestimmter Fedora Core Versionen sowohl Sicherheits-, als auch (begrenzte) Feature-Updates sehr breite Unterstützung Nutzung existierender fedora.us Verfahren (Build-System) Details: http://www.fedora.us/wiki/FedoraLegacy Probleme: zögerliche Akzeptanz seitens RH passt nicht in gegenwärtigen Bugzilla (Eigentümer von Komponenten sind global) vendorsec Paketmanagement Ziele: Fedora Extras + Alternatives keine ISOs -> Installation übers Netz automatisches Auflösen von Abhängigkeiten (automatisches) Einspielen von (Sicherheits)updates Verfahren: blanke RPM Kommandozeile Skriptlösungen (autorpm, GRAB, ...) up2date/Red Hat Network (RHN) apt yum up2date entwickelt von Red Hat wesentlicher Bestandteil des Red Hat Networks authentifizierte Klienten, Übergang Paket- zu Systemmanagement ermöglicht Bezahlfunktionalität Server-Software nur Red Hat intern; keine bzw. nur wenig verbreitete freie Lösungen APT basierend auf Debian’s "apt" portiert von Conectiva (Alfredo Kojima (Version 0.3), Gustavo Niemeyer (Version 0.5+)) rpm-Port wahrscheinlich in offizielles "apt" Details: http://moin.conectiva.com.br/AptRpm Vorteile: sehr gut konfigurierbar "Synaptic" Frontend (http://www.nongnu.org/synaptic/) Nachteile: keine direkte Nutzung der RPM-Funktionen: Nacheinander-Ausführen von "rpm -e" und "rpm -U" Nutzung des "--nodeps" Parameters Re-Implementierung von "rpm" Funktionen YUM "Yellow dog Updater, Modified" Autor: Seth Vidal, Duke University geschrieben
Load more

Recommended publications
  • Fedora Core Works--Without the Fluff That Bogs Down Other Books and Help/How-To Web Sites
    Fedora Linux By Chris Tyler ............................................... Publisher: O'Reilly Pub Date: October 01, 2006 ISBN-10: 0-596-52682-2 ISBN-13: 978-0-596-52682-5 Pages: 504 Table of Contents | Index "Neither a "Starting Linux" book nor a dry reference manual, this book has a lot to offer to those coming to Fedora from other operating systems or distros." -- Behdad Esfahbod, Fedora developer This book will get you up to speed quickly on Fedora Linux, a securely-designed Linux distribution that includes a massive selection of free software packages. Fedora is hardened out-of-the-box, it's easy to install, and extensively customizable - and this book shows you how to make Fedora work for you. Fedora Linux: A Complete Guide to Red Hat's Community Distribution will take you deep into essential Fedora tasks and activities by presenting them in easy-to-learn modules. From installation and configuration through advanced topics such as administration, security, and virtualization, this book captures the important details of how Fedora Core works--without the fluff that bogs down other books and help/how-to web sites. Instead, you can learn from a concise task-based approach to using Fedora as both a desktop and server operating system. In this book, you'll learn how to: Install Fedora and perform basic administrative tasks Configure the KDE and GNOME desktops Get power management working on your notebook computer and hop on a wired or wireless network Find, install, and update any of the thousands of packages available for Fedora Perform backups, increase reliability with RAID, and manage your disks with logical volumes Set up a server with file sharing, DNS, DHCP, email, a Web server, and more Work with Fedora's security features including SELinux, PAM, and Access Control Lists (ACLs) Whether you are running the stable version of Fedora Core or bleeding-edge Rawhide releases, this book has something for every level of user.
    [Show full text]
  • Spacewalk 2.4 for Oracle® Linux Concepts and Getting Started Guide
    Spacewalk 2.4 for Oracle® Linux Concepts and Getting Started Guide E71709-03 January 2017 Oracle Legal Notices Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Foot Prints Feel the Freedom of Fedora!
    The Fedora Project: Foot Prints Feel The Freedom of Fedora! RRaahhuull SSuunnddaarraamm SSuunnddaarraamm@@ffeeddoorraapprroojjeecctt..oorrgg FFrreeee ((aass iinn ssppeeeecchh aanndd bbeeeerr)) AAddvviiccee 101011:: KKeeeepp iitt iinntteerraaccttiivvee!! Credit: Based on previous Fedora presentations from Red Hat and various community members. Using the age old wisdom and Indian, Free software tradition of standing on the shoulders of giants. Who the heck is Rahul? ( my favorite part of this presentation) ✔ Self elected Fedora project monkey and noisemaker ✔ Fedora Project Board Member ✔ Fedora Ambassadors steering committee member. ✔ Fedora Ambassador for India.. ✔ Editor for Fedora weekly reports. ✔ Fedora Websites, Documentation and Bug Triaging projects volunteer and miscellaneous few grunt work. Agenda ● Red Hat Linux to Fedora & RHEL - Why? ● What is Fedora ? ● What is the Fedora Project ? ● Who is behind the Fedora Project ? ● Primary Principles. ● What are the Fedora projects? ● Features, Future – Fedora Core 5 ... The beginning: Red Hat Linux 1994-2003 ● Released about every 6 months ● More stable “ .2” releases about every 18 months ● Rapid innovation ● Problems with retail channel sales model ● Impossible to support long-term ● Community Participation: ● Upstream Projects ● Beta Team / Bug Reporting The big split: Fedora and RHEL Red Hat had two separate, irreconcilable goals: ● To innovate rapidly. To provide stability for the long-term ● Red Hat Enterprise Linux (RHEL) ● Stable and supported for 7 years plus. A platform for 3rd party standardization ● Free as in speech ● Fedora Project / Fedora Core ● Rapid releases of Fedora Core, every 6 months ● Space to innovate. Fedora Core in the tradition of Red Hat Linux (“ FC1 == RHL10” ) Free as in speech, free as in beer, free as in community support ● Built and sponsored by Red Hat ● ...with increased community contributions.
    [Show full text]
  • Openshift Virtualization Aka Container-Native Virtualization (CNV)
    OpenShift virtualization Aka Container-native virtualization (CNV) Robert Bohne SR. SPECIALIST SOLUTION ARCHITECT | OPENSHIFT Twitter: @RobertBohne 1 Red Hat OpenShift and OpenShift virtualization Modernize workloads and support mixed applications consisting of VMs, containers, and serverless ● Accelerate application delivery with a single platform that can manage “mixed VMs Containers applications” with the same tools and teams Red Hat OpenShift Container Platform ● Add VMs to new and existing applications ● Modernize legacy VM applications over Red Hat Enterprise Linux CoreOS time, or maintain them as VMs Physical machine 2 V0000000 KVM-based (containerized) VMs ● KVM is a part of the Red Hat Enterprise Linux kernel OTHER APPS libvirt ● QEMU uses KVM to execute virtual machines QEMU ● libvirt provides a management abstraction RHEL layer KVM ● Red Hat Virtualization, Red Hat OpenStack DRIVER DRIVER DRIVER Platform, and OpenShift virtualization all leverage KVM, QEMU, and libvirt CPU/RAM STORAGE NETWORK HARDWARE 3 Containerized virtual machines ● Inherit many features and functions from Kubernetes ○ Scheduling, high availability, attach/detach resources ● Containerized virtual machines have the same limitations as non-containerized ○ CPU, RAM, etc. limitations dictated by libvirt and QEMU ○ Linux and Windows guest operating systems ● Storage ○ Use Persistent Volumes Claims (PVCs) for VM disks ○ Containerized Data Importer (CDI) import VM images ● Network ○ Inherit pod network by default 4 ○ Multus enables direct connection to external network Architectural Overview kubelet (DaemonSet) Pod VM Pod Other Pod(s) API Server virt-handler virt-launcher container 1 virt-controller libvirtd container 2 VM container n Cluster Services Nodes 5 KubeVirt ▸ Open Source, Go ▸ Initiated in 2016 by Red Hat ▸ Contributions by other companies e.g (v)GPU support by Nvidia ▸ CNCF sandbox project since 2019 ▸ Provides an API for running KVM based virtual machines in Kubernetes ▸ Goal: run those VMs alongside with containerized workloads, using the same networks / storage etc.
    [Show full text]
  • Openshift Container Platform 4.6 Architecture
    OpenShift Container Platform 4.6 Architecture An overview of the architecture for OpenShift Container Platform Last Updated: 2021-09-22 OpenShift Container Platform 4.6 Architecture An overview of the architecture for OpenShift Container Platform Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • Fedora (Operating System) 1 Fedora (Operating System)
    Fedora (operating system) 1 Fedora (operating system) Fedora Fedora 17 (Beefy Miracle) running GNOME Shell 3.4 Company / developer Fedora Project, (sponsored by Red Hat, Inc.) OS family Unix-like (based on Red Hat Linux) Working state Current [1] Source model Free and open source software (with exceptions) [2] Initial release 2003-11-16 It was codenamed Yarrow. Fedora Core 1 was based on Red Hat Linux 9 and shipped with version 2.4.19 [3] of the Linux kernel, version 2.4 of the GNOME desktop environment, and K Desktop Environment 3.1. Latest stable release 17 (Beefy Miracle) / May 29, 2012 Available language(s) Multilingual Update method Yum (PackageKit) Package manager RPM Package Manager Supported platforms i686, x86-64 Kernel type Monolithic (Linux) Userland GNU Default user interface GNOME 3 [1] License Various free software licenses, plus proprietary binary blobs. Official website [4] www.fedoraproject.org Fedora ( /fɪˈdɒr.ə/), formerly Fedora Core, is an RPM-based, general purpose collection of software, including an operating system based on the Linux kernel, developed by the community-supported Fedora Project and sponsored by Red Hat. Fedora’s flexibility makes it capable of serving as a digital repository for a variety of use cases. The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.[5] One of Fedora's main objectives is not only to contain software distributed under a free and open source license, but also to be on the leading edge of such technologies.[6][7] Fedora developers prefer to make upstream changes instead of applying fixes specifically for Fedora—this ensures that their updates are available to all Linux distributions.[8] Compared to more mainstream non-Linux operating systems, Fedora has a short life cycle.
    [Show full text]
  • How to Modernize AIX Applications In- Place Using Red Hat Openshift
    January 2021 How to Modernize AIX Applications In- place Using Red Hat OpenShift By: Angshuman Roy [email protected] IBM IT Economics Consulting & Research © 2021 IBM Corporation Enterprises are modernizing their application to bring in cloud-native capabilities that work in a Hybrid Multicloud environment. In its Total Economic Impact study, Forrester found that clients accelerated development cycles by up to 66% by modernizing (ibm.co/3fvl8d2). Quite often, these organizations are looking at multiple cloud providers to host different parts of their applications while keeping mission critical workloads in-house. According to Flexera 2020 State of the Cloud Report (bit.ly/3iYCCR4), 93% of enterprises are pursuing a multicloud strategy, which helps them from being tied to a single vendor. To make an application more portable across multiple clouds, it must run on a unifying platform. Red Hat® OpenShift® is that platform. OpenShift extends the Kubernetes with built-in tools to enhance app lifecycle development, operations and security. With OpenShift, clients can consistently deploy workloads across multiple public or private clouds with ease. This article will break down how my team modernized a banking application running on AIX®. We built a new User Interface and deployed it on Red Hat OpenShift running on the existing IBM Power Systems™ server, while the business logic continued to run on the AIX backend. We added new functionality that ran on three different public clouds: IBM Cloud™, Amazon Web Services and Microsoft® Azure. All these environments were managed using IBM Cloud Pak® for Multicloud Management, also running on POWER®. Advantages of Containers in App Modernization One of the most common approaches to modernizing legacy applications starts by containerizing them so that they can be migrated to cloud.
    [Show full text]
  • Cobbler Documentation Release 2.8.5
    Cobbler Documentation Release 2.8.5 Jörgen Maas Nov 19, 2020 Contents 1 About 3 1.1 Release Notes.........................................3 1.2 Distribution Support......................................5 1.3 Distribution Notes.......................................7 1.4 How We Model Things..................................... 13 2 Installation 15 2.1 Prerequisites.......................................... 15 2.2 Installing from packages.................................... 16 2.3 Installing from Source..................................... 18 2.4 Configuration Files....................................... 20 2.5 Relocating your installation.................................. 21 3 General 23 3.1 Cobbler Primitives....................................... 23 3.2 Cobbler Direct Commands................................... 54 3.3 Cobbler Settings........................................ 69 3.4 Managing Services with Cobbler............................... 90 3.5 Kickstart Templating...................................... 94 3.6 Snippets............................................ 102 3.7 Package Management and Mirroring............................. 112 3.8 File System Information.................................... 114 4 Advanced 119 4.1 Advanced Networking..................................... 119 4.2 SELinux............................................ 122 4.3 Configuration Management.................................. 123 4.4 Extending cobbler....................................... 131 4.5 Power Management...................................... 135 4.6
    [Show full text]
  • Openshift Container Platform 4.6 Release Notes
    OpenShift Container Platform 4.6 Release notes Highlights of what is new and what has changed with this OpenShift Container Platform release Last Updated: 2021-09-22 OpenShift Container Platform 4.6 Release notes Highlights of what is new and what has changed with this OpenShift Container Platform release Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent.
    [Show full text]
  • Scientific Linux - the Future of DESY Linux (?)
    Scientific Linux - The Future of DESY Linux (?) Stephan Wiesand DESY -DV - September 14, 2004 Outline What DESY Linux (DL) is What Scientific Linux (SL) is What Scientific Linux DESY (SLD) will be What the status of SLD3 is What will change from the user's point of view When it's going to happen DESY Linux base distribution criteria: usability, size, lifetime (availability of security fixes), use/acceptance in HEP, ISV support + bug fixes example: make screen lock usable in kerberized environment + customization examples: HEPiX, HEPiX11, continuity for users + additional software /opt/products + automatic installation, configuration and maintenance VAMOS/sue/cfengine Base Distribution Candidates: debian lifetime: 12 months after next release release cycle completely undefined when we picked the DL5 base distro last year, we wondered whether a new debian stable would be released the same year it wasn't, and the question remains the same debian stable is completely out of date not usable on current hardware not available for amd64 (platform younger than distro) not widely accepted in HEP debian is not for us Candidates: SuSE Professional current choice for DL5 8.2 9.0 for notebooks, amd64 defined release cycle: every 6 months defined lifetime: 2 years barely enough after release, security fixes only no bug fixes or enhancements not widely accepted in HEP acquisition by Novell may improve acceptance in US Candidates: SuSE Enterprise release cycle: 12-18 months lifetime: 5 years security fixes bug fixes, enhancements for < 5 years much shorter
    [Show full text]
  • Contents at a Glance
    04_579495 ftoc.qxd 12/27/04 9:52 PM Page xii Contents at a Glance Preface . vii Acknowledgments . xi Part I: Linux First Steps. 1 Chapter 1: Starting with Linux . 3 Chapter 2: Running Commands from the Shell . 29 Chapter 3: Getting into the Desktop . 77 Part II: Running the Show . 123 Chapter 4: Learning Basic Administration . 125 Chapter 5: Getting on the Internet . 169 Chapter 6: Securing Linux . 191 Part III: Choosing and Installing a Linux Distribution . 241 Chapter 7: Installing Linux . 243 Chapter 8: Running Fedora Core and Red Hat Enterprise Linux . 273 Chapter 9: Running Debian GNU/Linux . 295 Chapter 10: Running SUSE Linux . 315 Chapter 11: Running KNOPPIX . 329 Chapter 12: Running Yellow Dog Linux . 351 Chapter 13: Running Gentoo Linux . 367 Chapter 14: Running Slackware Linux . 383 Chapter 15: Running Linspire . 399 Chapter 16: Running Mandrakelinux . 409 Chapter 17: Running a Linux Firewall/Router . 423 Chapter 18: RunningCOPYRIGHTED Bootable Linux Distributions MATERIAL . 447 Part IV: Running Applications . 459 Chapter 19: Playing Music and Video . 461 Chapter 20: Working with Words and Images . 501 Chapter 21: E-Mailing and Web Browsing . 541 Chapter 22:Gaming Alone and Online . 569 04_579495 ftoc.qxd 12/27/04 9:52 PM Page xiii Part V:Running Servers . 593 Chapter 23: Running a Linux, Apache, MySQL, and PHP (LAMP) Server . 595 Chapter 24: Running a Mail Server . 617 Chapter 25: Running a Print Server . 635 Chapter 26: Running a File Server . 659 Part VI: Programming in Linux. 693 Chapter 27: Programming Environments and Interfaces . 695 Chapter 28: Programming Tools and Utilities .
    [Show full text]
  • Best Practices Best Practices
    Best Practices Best Practices Publication Date: 2019-09-03 SUSE LLC 10 Canal Park Drive Suite 200 Cambridge MA 02141 USA https://www.suse.com/documentation Contents 1 Introduction 1 1.1 What’s Covered in this Guide? 1 1.2 Prerequisites 1 1.3 Network Requirements 3 1.4 Hardware Recommendations 6 2 Managing Your Subscriptions 9 2.1 SUSE Customer Center (SCC) 9 2.2 Disconnected Setup with RMT or SMT (DMZ) 9 Repository Management Tool (RMT) and Disconnected Setup (DMZ) 10 • Repository Management Tool (SMT) and Disconnected Setup (DMZ) 11 • Updating Repositories on SUSE Manager From Storage Media 12 • Refreshing Data on the Storage Medium 13 3 Expanded Support 15 3.1 Managing Red Hat Enterprise Linux Clients 15 Server Configuration for Red Hat Enterprise Linux Channels 15 • Red Hat Enterprise Linux Channel Management Tips 16 • Mirroring RHEL Media into a Channel 16 • Registering RES Salt Minions with SUSE Manager 17 • Register a Salt Minion via Bootstrap 19 • Manual Salt Minion Registration 20 3.2 Preparing Channels and Repositories for CentOS Traditional Clients 20 3.3 Registering CentOS Salt Minions with SUSE Manager 23 3.4 Managing Ubuntu Clients 24 3.5 Prepare to Register Ubuntu Clients 25 iii Best Practices 4 Salt Formulas and SUSE Manager 28 4.1 What are Salt Formulas? 28 4.2 Installing Salt Formulas via RPM 28 4.3 File Structure Overview 30 4.4 Editing Pillar Data in SUSE Manager 31 Simple edit-group Example 38 4.5 Writing Salt Formulas 41 4.6 Separating Data 42 4.7 SUSE Manager Generated Pillar Data 43 4.8 Formula Requirements 44 4.9
    [Show full text]