Giter Club home page Giter Club logo

documentation's Introduction

Contribution Guide

All Contributors

Introduction

With Rocky Linux emerging as a major RHEL-compatible distribution, this is an exciting time in the open source community. Rocky Linux’s mission is to provide companies and individuals with a stable foundation of open source software for their enterprise and HPC needs. We are here to support that mission with excellent documentation.

To us, excellent documentation hits these marks:

  • Educate users on how to administer this distribution and its associated programs.
  • Support users of all skill levels with manuals and troubleshooting guides to make the most of this distribution.
  • Apply a consistent standard across all related documents, for ease of reading and translation.
  • Keep documentation up to date (and error free) with current versions.
  • Allow users to contribute Guides, Docs, Gemstones (scripts and favorite code snippets) and more, to enhance Rocky Linux for fellow users.

We welcome anyone who wants to be part of this mission. No specific degree, years of experience, or company affiliation is required. Be bold! We promise, you won’t break anything even if you fumble your first attempt.

License

Documents written by the rocky linux documentation team are published under the Creative Commons-BY-SA license. This means you are free to copy, distribute and transform the works, while respecting the author's rights.

  • BY: Attribution. You must cite the name of the original author.
  • SA: Share Alike.

Creative Commons-BY-SA license

The documents and their sources are freely downloadable from:

Our media sources are hosted at github.com. You'll find the source code repository where the version of this document was created.

Technical requirements

Our standards for Rocky documentation.

Style Guide

The RL Style Guide outlines standards for the wording within your document.

GitHub

Rocky Linux uses GitHub to manage its code and files, including documentation files. Login to GitHub and follow the official Rocky Linux documentation repository.

Markdown

Documentation is welcome in whatever format you are used to creating. It does not need to be perfect, just submit what you have and the team will give you feedback to help get it in line with our voice and tone.

That said, RL Documentation uses Markdown as the standard. It is easy to learn and use. Run a text converter on your content or start from scratch with this basic writing and formatting guide. For more information on writing markdown with proper formatting, see our guide.

As you become a regular contributor, you’ll need to create a local repository. See our guide for how to install a Markdown editor and create a local repository on your home computer.

Contribution Process

The actual process of reporting an issue, revising, or creating a doc. Please see special notes afterward about translations, links, and meta content.

Report an issue

Maybe you’ve found a broken link or incorrect information while exploring the Rocky docs. This is called an issue, and we want to know about it. You can mention it on the Mattermost Documentation channel, or visit GitHub and make a proper issue report. GitHub has a handy guide for how to create an issue.

Submit an update

Add a missing word, correct an error, or clarify a confusing bit of text. You won’t break anything because someone will review your contribution before it goes live. Here is the basic process.

  1. Start on the page you want to update on https://docs.rockylinux.org/.

    Click the “Edit” pencil in the upper right corner of the document. You will be taken to the original document stored on GitHub.

    The first time you contribute to the RL repository, you will be prompted with a green button to “Fork this repository and propose changes.” This creates a duplicate copy of the RL repository where you make your suggested edits. Click the green button and continue.

  2. Make your changes

    Follow the existing Markdown formatting. Make the necessary change.

  3. Propose changes

    At the bottom of the page, write a brief description in the title of the block entitled Propose changes.

    Then click Propose changes, which will Commit your changes to a completed document within your forked repository.

  4. Review changes

    Now you can look at what you’ve done, line by line. If you missed anything, back up to the previous page and correct it again (you’ll have to start over), then click Propose Changes again.

    Once the doc is the way you want it, click the green button that says Create Pull Request. This provides one more chance to double check your changes and confirm the doc is ready.

  5. Create Pull Request

    So far you have been working in your own repository. Next you submit it to the documentation team to merge your version into the main version of the document.

    Click the green button that says Create Pull Request, which sends it to the RL documentation team for review.

  6. Wait

    Once the RL team reviews your request, they will respond in one of three ways.

    • Accept and merge your PR
    • Comment with feedback and ask for changes
    • Deny your PR with explanation

    If you have to make changes, you will suddenly understand why you need a local repository. The team can talk you through what to do next. In good news, it’s still fixable.

Need more in-depth explanation? Here are the same directions with more elaboration under the heading, "Submit an update."

Success? Welcome to the team, you are officially a Rocky Linux documentation contributor. Your profile will be added to the contributor list at the bottom of this document shortly.

Become a frequent contributor

For more than a word or two of occasional edits, we recommend that you setup a local repository on your own machine. From there, you can revise documentation from your clone of the RL repository, Commit it to your online GitHub repository, and then create Pull Requests to merge with the main repository.

Advanced users may wish to create a complete documentation server on your local Linux workstation or VM. We have guides to set that up with Docker or LXD. We also have a fast documentation system with special caveats if you are using Python on the same server.

Submit a new document

Rocky Linux documentation includes guides, books, labs, and gemstones. Your original contributions are welcome in any of these categories.

Meta

Please include the following meta information at the top of all new documentation:

---
title: Document title
author: the author of the source (English) version of the document.
contributors: a comma separated list of contributors to the source document.
tested with: a comma separated list of versions, for example 8.6, 9.0
tags:
- displayable tags
- these are also searchable
- they are two space indented and start with a "-" as shown here
- generally, they should be one word
---

Formatting

To add more advanced elements to your Markdown-formatted document beyond text, visit the formatting guide. This covers Admonitions, Tables, Quotes, and more.

Contribute

The process for submitting original content is similar to updating an existing document from your local repository. Create a new document within your Markdown editor, Commit it to your GitHub repository, then submit a Pull Request to merge into the main branch of the repository. The documentation leads will decide where the new document will live.

Special Notes

Links

Links can be internal (other docs within our domain), external (publicly hosted URLs), or lab-based (used as examples within your document).

The format for all links within the documentation is square brackets around the descriptive name or label:

[our site] followed by your link in parenthesis: (https://example.com)

To help lab-based URLs pass our automatic URL checker, we have created a list of excluded names you may use. You may request that a new exclusion be added. An editor may adjust your lab-based URL, or add an exclusion if they think it is warranted.

Please note the following IEEE recommendation on naming local networks RFC #8375 Special-Use Domain 'home.arpa.' published in May 2018.

  • home.arpa
  • example.com
  • site.com
  • site1.com
  • site2.com
  • apache-server
  • nginx-server
  • your-server-ip
  • your-server-hostname
  • localhost

Translation

CrowdIn

We are adding to these docs in new languages at the speed of getting translators on board. Seeking contributors for this area especially. We use CrowdIn for updates.

Translation and Meta content

Translators, if you find a word in the source document that does not translate well into your language, or an error that prevents a perfect translation, please fix that in the source document and make a Pull Request. In that case, please add yourself as a contributor in the meta content of that document.

However, unless you modify the source document, please do not modify the meta content.

The place where we do want to acknowledge you is in the all-contributors section--at the bottom of this page. This is a list of everyone who has been part of this documentation project, whether creating content, spotting and fixing errors, or translating. Translators, you may add yourself (or request to be added) here. We appreciate your contribution!

Communication channel

For reporting issues, asking questions, getting support, and getting to know the documentarians.

For general questions about installing and using the distro, visit our community forums. For questions about the behind-the-scenes stuff like documentation, we have other channels.

Mattermost

To ask real-time questions, create a profile on the Mattermost server, then navigate to the Rocky Linux General or Documentation channel--or whichever channel seems appropriate to your question. You should get a response within hours if not right away.

Welcome aboard! Meet the rest of our awesome contributors below: (emoji key):

wale soyinka
wale soyinka

📆 🚧 🖋
sspencerwire
sspencerwire

📆 🚧 🖋
Ezequiel Bruni
Ezequiel Bruni

🚧 🖋
ambaradan
ambaradan

🌍
Antoine Le Morvan
Antoine Le Morvan

🖋 🌍
tianci li
tianci li

🖋 🌍
student
student

🖋
NezSez
NezSez

🖋 🤔
justasojourner
justasojourner

🖋 🤔
Neil Hanlon
Neil Hanlon

🖋 🚧 🤔
Peter Ajamian
Peter Ajamian

🖋
Flávio Siqueira Prado
Flávio Siqueira Prado

🌍
Norio4
Norio4

🌍
Sébastien Pascal-Poher
Sébastien Pascal-Poher

🌍
Lucas Trecanao
Lucas Trecanao

🌍
calderds
calderds

🖋 👀
execion
execion

🌍
lillolollo
lillolollo

🖋
Ahmed alBattashi
Ahmed alBattashi

🖋
StackKorora
StackKorora

🖋
3xtant
3xtant

🖋
almrv
almrv

🌍
Hayden
Hayden

🖋
Louis Abel
Louis Abel

🖋
Ron
Ron

🖋
Amin Vakil
Amin Vakil

🖋
K.Prasad
K.Prasad

🖋
IncorrigiblyBelligerent
IncorrigiblyBelligerent

🖋
Jairo Nonato Júnior
Jairo Nonato Júnior

🖋
Saif Eddine Halila
Saif Eddine Halila

🖋
DrCool2
DrCool2

🖋
codedude
codedude

🖋
Graham
Graham

🖋
Aditya Putta
Aditya Putta

🖋
yangxuan74
yangxuan74

🖋
Morgan Read
Morgan Read

🖋
9p4
9p4

🖋
Alex Zimmerman
Alex Zimmerman

🖋
Andrew Faulkner
Andrew Faulkner

🖋
Todd Levi
Todd Levi

🖋
tahder
tahder

🖋
Takahiro Yoshihara
Takahiro Yoshihara

🖋
Gerard Arthus
Gerard Arthus

🖋
HadManySons
HadManySons

🖋
Brandon Mayfield
Brandon Mayfield

🖋
Anthony Staunton
Anthony Staunton

🖋
whg517
whg517

🖋
MrSkribb
MrSkribb

🖋
jules
jules

🖋
bittin
bittin

🖋
ichibariki
ichibariki

🖋
Bernat Puigdomenech Pascual
Bernat Puigdomenech Pascual

🖋
Dennis Körner
Dennis Körner

🖋
Pedro Bezunartea López
Pedro Bezunartea López

🌍
Daniel Pogac
Daniel Pogac

🖋
oats
oats

🖋
Alex Harden
Alex Harden

🖋
Jordan Pisaniello
Jordan Pisaniello

🖋
Richard Hennig
Richard Hennig

🖋
caffenix
caffenix

🖋
Lento Manickathan
Lento Manickathan

🖋
Alan Sill
Alan Sill

🖋
Ikko Ashimine
Ikko Ashimine

🖋
William Perron
William Perron

🖋
Roman Gherta
Roman Gherta

🖋
Yiğit can BAŞALMA
Yiğit can BAŞALMA

🖋
markooff
markooff

🖋 🌍
Deng Wenbin
Deng Wenbin

🌍
alikates
alikates

🖋
hopnux
hopnux

🌍
Pedro Garcia Rodriguez
Pedro Garcia Rodriguez

🌍
Lau
Lau

🖋
Serge Croisé
Serge Croisé

🖋
bamtests
bamtests

🖋
jahway603
jahway603

🖋
Nejc Bertoncelj
Nejc Bertoncelj

🖋
Dan Baker
Dan Baker

🖋
Laura Hild
Laura Hild

🖋
Grammaresque
Grammaresque

🖋
Rawk Akani
Rawk Akani

🖋
nm583
nm583

🖋
MrPaulAR
MrPaulAR

🖋
cybernet
cybernet

🖋
Jan Kytka
Jan Kytka

🖋
Mario
Mario

🖋
Ganna Zhyrnova
Ganna Zhyrnova

🌍
Travis W
Travis W

🖋
Tej Singh Rana
Tej Singh Rana

🖋
Aditya Roshan Dash
Aditya Roshan Dash

🖋
qyecst
qyecst

🖋
Matt
Matt

🖋
zdover23
zdover23

🖋
Mani Yadla
Mani Yadla

🖋
Dave_Barnabas
Dave_Barnabas

🖋
Neel Chauhan
Neel Chauhan

🖋
Joey
Joey

🖋
Emre Çamalan
Emre Çamalan

🖋
Yash Pandey
Yash Pandey

🖋
Stephen Simpson
Stephen Simpson

🖋
Srinivas Nishant Viswanadha
Srinivas Nishant Viswanadha

🖋
Stein Arne Storslett
Stein Arne Storslett

🖋
Chris Pepper
Chris Pepper

🖋

This project follows the all-contributors specification. Contributions of any kind welcome!

documentation's People

Contributors

ajthiesen avatar alemorvan avatar allcontributors[bot] avatar ambaradan avatar aminvakil avatar bittin avatar ezequielbruni avatar gannazhyrnova avatar garthus1 avatar grammaresque avatar hbjydev avatar jimcat8 avatar justasojourner avatar lillolollo avatar ltrecanao avatar lumarel avatar nazunalika avatar neelchauhan avatar neilhanlon avatar nezsez avatar nishaaaaaant avatar norio4 avatar payagej avatar puttaap avatar rockylinux-auto avatar sergecroise avatar sspencerwire avatar wsoyinka avatar yangxuan74 avatar yashpandey06 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

documentation's Issues

Remove "Rocky Linux" and "Rocky" from the page titles

This isn't as critical as my other issue, but I still think it's important.

In the context of a documentation site for a product, having the name of the product repeated in every title to me doesn't seem like something we want.

I'll happily be overruled on this, but I definitely think it wants correcting.

Unable to find module when running `dnf module enable nginx:mainline`

I was reading the article about setting up nginx here: https://docs.rockylinux.org/guides/web/nginx-mainline/#installing-the-repository

The guide recommends running dnf module enable nginx:mainline which results in the following error:

[root@3b221b8ee080 /]# dnf module enable nginx:mainline
Last metadata expiration check: 0:00:58 ago on Thu Mar 10 02:30:37 2022.
Error: Problems in request:
missing groups or modules: nginx:mainline

If I run dnf module list nginx, I don't see mainline listed as a stream.

[root@3b221b8ee080 /]# dnf module list nginx
Last metadata expiration check: 0:01:26 ago on Thu Mar 10 02:30:37 2022.
Rocky Linux 8 - AppStream
Name                                Stream                                Profiles                                Summary
nginx                               1.14 [d]                              common [d]                              nginx webserver
nginx                               1.16                                  common [d]                              nginx webserver
nginx                               1.18                                  common [d]                              nginx webserver
nginx                               1.20                                  common [d]                              nginx webserver

[FR] Basic Document Templates

I created this issue, so I could use it to link to a related PR I'll submit later; just another test of using GH capabilities.
linking-a-pull-request-to-an-issue

This is a feature request to create template documents with appropriate GH markdown in place to provide an easy to use starting document for contributors to use. Presumably we'd want one for each basic type of document or genre published:
books, gemstones, guides, labs, release_notes, and possibly one to use for the GH "Wiki" link (not to be confused with other RL Wikis).

Translate docs/index.md into German

Das Issue enthält 5 verschiedene Tasks, die nacheinander durchgeführt werden sollten.
Diese Tasks entsprechen 5 verschiedene Rollen, die mehrere Teilnehmer (2 Personen oder mehr) nach dem Team-Translating Prinzip abwechselnd übernehmen können.

  1. english reviewer: Review the base english article (punctuation, vocabulary, grammar, ...):
    https://docs.rockylinux.org/en/
    https://github.com/rocky-linux/documentation/edit/main/docs/index.md
  2. translator: Propose german translations with Crowdin:
    https://crowdin.com/translate/rockydocs/523/en-de
    https://crowdin.com/translate/rockydocs/221/en-de
    https://crowdin.com/translate/rockydocs/109/en-de
    https://crowdin.com/translate/rockydocs/412/en-de
  3. reviewer for german (crowdin): Review the german translations in crowdin
    (downvote or delete wrong translations, upvote good translations)
  4. proofreader (crowdin): Approve the german translations with Crowdin, (todo)
  5. external reviewer for german: Review the final result in german, (todo):
    https://docs.rockylinux.org/de/

Tip:
Um Konflikte mit dem Übersetzungs-Tool (hier Crowdin) zu vermeiden,
sollte man erst mit den Punkten 2.,3. und 4 anfangen, wenn Task Nr. 1 abgeschlossen ist.

Documentation section for "Enterprise"?

While taking notes on setting things up I've noticed that many of our docs are geared for small installations as opposed to actual enterprise usage where LDAP, Kerberos (and AD integration), Actual use of Certificate Authorities, Certs/Key management (ssh, 509, PKI, etc), AFS(Andrew not Apple)/Ceph/ZFS/SAN/NAS/FC/iSCSI, dbase sharding, etc etc are not addressed at all. Should we create a section specific to such enterprise configurations?

As a real-world example, setting up KVM to do live migrations between hosts is a bit more complex and requires things which are not needed at all for a standalone setup on one desktop home server like NFS and SR-IOV of intel 40GB NICs. A college admin setting up a system for students to run containers or VMs on during a class is very different than one person setting this up for home/hobby usage (multi-user security, encrypted memory space/shared mem, etc). iDRAC, IPMI/LOM, OpenManage, and HA/HPC clusters would be other examples.

Putting some of these topics in with the list as we have it now would likely just confuse many users who aren't concerned with such setups, may never have heard of most of these topics, and make for confusing or annoying navigation for someone who just wants things to work without understanding all the details.

I have no agenda, just trying to be considerate. It may not be worth the effort of splitting such topics out at this stage; perhaps once we get more docs, but preventative front-loading can save much hassle later.

Translate markdown-demo-v2 into German

Deutsche Reviewer gesucht!

Das Issue enthält 5 verschiedene Tasks, die nacheinander durchgeführt werden sollten.
Diese Tasks entsprechen 5 verschiedene Rollen, die mehrere Teilnehmer (2 Personen oder mehr) nach dem Team-Translating Prinzip abwechselnd übernehmen können.

  1. english reviewer: Review the base english article (punctuation, vocabulary, grammar, ...):
    https://docs.rockylinux.org/en/gemstones/markdown-demo-v2/
    https://github.com/rocky-linux/documentation/edit/main/docs/gemstones/markdown-demo-v2.md
  2. translator: Propose german translations with Crowdin:
    https://crowdin.com/translate/rockydocs/422/en-de
  3. german reviewer (crowdin): Review the german translations in crowdin,
    downvote or delete wrong translations, upvote good translations, (done).
  4. proofreader: Approve the german translations with Crowdin, (TODO).
  5. external german reviewer: Review the final result in german, (TODO):
    https://docs.rockylinux.org/de/gemstones/markdown-demo-v2/

Tip:
Um Konflikte mit dem Übersetzungs-Tool (hier Crowdin) zu vermeiden,
sollte man erst mit den Punkten 2.,3. und 4 anfangen, wenn Task Nr. 1 abgeschlossen ist.

SIG links on Contributing/getting-started page

This issue has been moved to Issue #3 on the RL Wiki

Under Requesting Access to Groups/SIGs
"Find the group or groups you wish to join and find the sponsors"
has only a link to the generic MatterMost url.

Should this have links to actually help someone find groups/SIGS easily like:
https://wiki.rockylinux.org/team
https://wiki.rockylinux.org/special-interest-groups
https://lists.resf.org/mailman3/lists/

Or links to the actual MM SIG channels:
(list is not all encompassing, just the ones I currently know of)

AltArch SIG
Containers SIG
GOV(US) SIG
HPC SIG
Kernel SIG
Plus specific packages SIG
Virtualization SIG

Or a list like:
Alternative Architectures SIG:
MatterMost Chat Channel , Maillist, Wiki

Update NvChad docs

Hi there! author of NvChad here. v2.0 has recently released https://nvchad.com/news and it uses lazy.nvim instead of packer.nvim for package manager. There are few breaking changes ( mostly related to package manager ) but the config has gotten easier.

old syntax is depreceated ( people can still use it tho! )

documentation/docs/guides/custom-linux-kernel.md additional info

@wsoyinka I don't know if you would want to include the following info, or where you'd want to put it if you do, but for RHEL/CentOS/RL et. al. you can see what your installed kernels were config'd with :
cat /boot/config-<kernel-ver>
So one could use the following to check the currently running kernel versions' config:
cat /boot/config-$(uname -r) | grep -i <some-keyword>
It will show "=m", or "=y" if configured, but doesn't have entries for anything NOT configured
(i.e. it will not show "=n")

Found a little typo in your docs

Hi guys,

I just wanted to let you know about a little typo in your docs on the page "Postfix Process Reporting" -> "Testing Mail First".

cp /etc/**postifix**/main.cf /etc/postfix/main.cf.bak

P.S. I'm new to Rocky Linux but till now I'm more than happy with it. Thanks!

Kind Regards,
Dennis Bitsch

Translate docs/index.md into Ukrainian

  1. english reviewer: Review the base english article (punctuation, vocabulary, ...):
    https://docs.rockylinux.org/en/
    https://github.com/rocky-linux/documentation/edit/main/docs/index.md
  2. translator: Propose ukrainian translations with Crowdin:
    https://crowdin.com/translate/rockydocs/523/en-uk
  3. ukrainian reviewer (crowdin): Review the ukrainian translations in crowdin (downvote or delete wrong translations, upvote good translations, ...)
  4. proofreader: Approve the ukrainian translations with Crowdin
  5. external ukrainian reviewer: Review the final result in ukrainian:
    https://docs.rockylinux.org/uk/

iptables enable instruction is incorrect

In the docs/guides/enabling_iptables_firewall.md I believe the instruction to enable iptables is incorrect:

Now we need to enable the iptables service to make sure that it starts on boot:

'dnf enable iptables'

that the command should be:

'systemctl enable iptables'

Failed to install devtools on Rocky Linux 9

I follow instructions to install devtools on Rocky Linux 9 but get the following error message:

$ sudo make install
sudo dnf config-manager --set-enabled powertools
Error: No matching repo to modify: powertools.
make: *** [Makefile:12: .system] Error 1

I'm newbie of RL .

list of excluded (domain or network) names

I'll make some additions to the list at:
contribute-Special Notes
As there is an actual, official, RFC/STD for the use of home.arpa for local only domains.
I'll include some examples of how other listed were never actual stds and in some cases were hijacked (demonstrable even now) by someone purchasing that name.

IPA Administration Book

I'd like to create (or see created) a book on deploying a FreeIPA/IdM installation on Rocky. I'm hoping to make this the first of some "what I learned deploying Rocky in a corporate environment" contributions I want to make. :)

I've got some decent experience working with it so far, and I'd like to contribute, and I should be able to next week.


Note: Everywhere "(CLI & UI)" appears, the CLI method is 100% preferred over the UI and will likely be done first.

  • Installing IdM
    • From Scratch
    • With Ansible
  • Deploying a master
    • From Scratch
    • With Ansible
  • Configuring Users
    • From Scratch (CLI & UI)
    • With Ansible
  • Configuring Groups
    • From Scratch (CLI & UI)
    • With Ansible
  • Configuring HBAC
    • From Scratch (CLI & UI)
    • With Ansible
  • Configuring Sudo
    • From Scratch (CLI & UI)
    • With Ansible
  • Configuring DNS
    • From Scratch (CLI & UI)
    • With Ansible
  • Configuring CA
    • From Scratch (CLI & UI)
    • With Ansible
  • Deploying a client
    • From Scratch
    • With Ansible
  • Deploying a replica
    • From Scratch
    • With Ansible

Some 'maybes':

  • Promoting a new master
  • AD Trust Setup (though this could maybe be its own collection of docs, not just one guide, go over different approaches)
  • Managing replicas (listing, deleting, etc.)
  • Disaster recovery
  • Production checklist (covers things like resources, considerations, networking, backups (or lack thereof, in this case), etc.)

Nginx proxy_pass not working with SELinux in enforce mode

Need to add to documentation a special observation to disable "setenforce 0"
or better off, "sudo setsebool httpd_can_network_connect 1 -P" , or some better instructions to allow nginx through SELinux

Othewise the nginx proxy_pass capabilities will not work throwing a "502 Bad Gateway" error

Crossgrade from CentOS to Rocky

I know I've seen written it in a few places that Rocky is intended to be bug for bug compatible.

Does this mean it's just a question of changing the yum repos on my CentOS 8 install, and renaming my distro (/etc/redhat-release) and it will follow Rocky upgrades? Or is something more complex necessary?

Looking forward to the release - nice work, everyone ❤️

Docker installation instructions say to use Docker's CentOS repository

The page https://docs.rockylinux.org/gemstones/docker/ says to use Docker's CentOS repository. This does not seem right: Rocky does not track CentOS, rather RHEL. However, I see that Docker's RHEL repository covers only the IBM S390 architecture - https://docs.docker.com/engine/install/rhel/. The latter page suggests trying the CentOS repository for RHEL on x86_64.

To prevent everyone else to reads https://docs.rockylinux.org/gemstones/docker/ being confused and having to perform this same research, it would be useful if that page contained a little explanation of why Docker's CentOS repository was specified.

Differences between RL8 and RL9

Starting with the basic network configuration page here, there is likely other bits of guides/documentation that may not apply to certain Rocky Linux versions or processes have changed. The documentation should likely be evaluated as a result. Right now, there are users who frequently come to the general channel to ask about certain cases (especially the network-scripts being empty on Rocky Linux 9) being confused as some page assumes the configuration is the same on both 8 and 9.

There are a few things that should be considered:

  • Should each major version of Rocky Linux be separated (similar to Red Hat's documentation - this would require a large rework and may not be ideal at all) or...
  • Should each guide section that may have differences between Rocky Linux versions noted in subsections of certain steps on the guide pages or...
  • Should each guide section have a drop down for each relevant Rocky Linux version

One idea could be:

  • Going to the desktop section and clicking the drop down
  • See Rocky Linux 8 and Rocky Linux 9, and clicking the drop down for my system
  • Seeing the guides that apply for that release

Another idea could be having a button or a way to reflect a given release dynamically on a page (this may be a feature that isn't in mkdocs or a plugin). There are some docs pages out there that do this where selecting a version at the top will change commands or portions of the guide to reflect that release.

Generate the files index.fr.md and index.de.md

correction for gpg key in LXD server book

Hi,
I'm currently following the LXD server tutorial (using Rocky 8.7) and I'd like to propose a correction for this page: https://docs.rockylinux.org/books/lxd_server/01-install/

The part about the OpenZFS GPG key seems to be outdated. The file name is no longer /etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux but /etc/pki/rpm-gpg/RPM-GPG-KEY-openzfs.

Moreover, I'm not sure if that command actually "gets" the gpg key. Does it import it into gpg? After reading gpg's manpage I think "show-only" doesn't do that. I was asked to verify the gpg key by dnf when I installed zfs later on.

Import Rocky Linux to WSL

Hello,
In the official documentation to Import Rocky Linux to WSL please could you clarify how and where to find the container rootfs ?

We have this :
Download the image from the CDN images folder (if it is available)
Download the image from the latest Github Action build
Extract the image from either Docker Hub or Quay.io (ref.)

But in the CDN images folder the is no container rootfs I guess for windows user. In the Github Action build it looks the same I don't know what to use to import Rocky Linux to WSL.
And I don't have docker on my machine so I can't export the rootfs from a docker image.

Thank you very much for your help.

May be, is it plan to create an official WSL image that we can install from the Microsoft Store ?

Kernel guide should have warnings to users

The kernel building guide should be noting to users that building and maintaining their own kernel is unsupported and provide warnings to users who wish to build them. Our wiki actually states the following:

Kernel rebuilds are not recommended nor supported for Rocky Linux. Before building a custom kernel or even considering it, ask yourself the following questions:

* Is the functionality you need available by installing a kernel module from [elrepo](https://elrepo.org)?
* Is the functionality you need available as a separate module from the kernel itself?
* Are you willing to maintain your own security posture?
* **Are you sure**? Rocky Linux and most other EL derivatives were designed to function as a complete environment. Replacing critical components can affect how the system acts.
* **Are you ABSOLUTELY sure**? 99.9% of the users no longer need to build their own kernel. You may simple need a kernel module/driver, in which case, you can use [elrepo](https://elrepo.org) or build your own kernel module (kmod/dkms)
* **Are you sure you don't just want a newer kernel version**? Newer kernels can be found at [elrepo](https://elrepo.org)

As a final warning, you if you break the kernel, you are on the hook for your system. Rocky Linux volunteers or developers are unable to assist you with these issues.

While it is a nice-to-have guide for users who want to build their own kernel or are learning, similar warnings should be given on the kernel building guide.

Translate books/disa_stig/disa_stig_part1.md into German

Deutsche Reviewer gesucht!

Das Issue enthält 5 verschiedene Tasks, die nacheinander durchgeführt werden sollten.
Diese Tasks entsprechen 5 verschiedene Rollen, die mehrere Teilnehmer (2 Personen oder mehr) nach dem Team-Translating Prinzip abwechselnd übernehmen können.

  1. english reviewer: Review the base english article (punctuation, vocabulary, grammar, ...):
    https://docs.rockylinux.org/en/books/disa_stig/disa_stig_part1/
    https://github.com/rocky-linux/documentation/edit/main/docs/books/disa_stig/disa_stig_part1.md
  2. translator: Propose german translations with Crowdin:
    https://crowdin.com/translate/rockydocs/406/en-de
  3. german reviewer (crowdin): Review the german translations in crowdin,
    downvote or delete wrong translations, upvote good translations, (in progress).
  4. proofreader: Approve the german translations with Crowdin, (TODO).
  5. external german reviewer: Review the final result in german, (TODO):
    https://docs.rockylinux.org/de/books/disa_stig/disa_stig_part1/

Tip:
Um Konflikte mit dem Übersetzungs-Tool (hier Crowdin) zu vermeiden,
sollte man erst mit den Punkten 2.,3. und 4 anfangen, wenn Task Nr. 1 abgeschlossen ist.

dnf group install is incorrect

In the docs/guides/backup/mirroring_lsyncd.md, maybe the dnf install command is incorrect:

Install Dependencies

We will need some dependencies: a few that are required by lsyncd itself, and a few that are required to build packages from source. Use this command on your Rocky Linux machine to make sure you have the dependencies you need. If you are going to be building from source, it's a good idea to have all of the development tools installed:

dnf install groupinstall 'Development Tools'

that the command should be?

dnf group install 'Development Tools'

Code block formatting

Okay, to continue the discussion from my earlier PR re: code in its own line or paragraph.

The Basics
I'd like to use this:

Run this command:

```bash
the-command
```

And not:

Run this command:

`the-command`

Now people have been focusing on on whether we should use the syntax-defining feature as shown in the first example. To clear a couple of things up, I'd first like to mention, as others have, there you can do this for a bunch of languages, not just bash.

Secondly, while I see defining the syntax as a big benefit of this formatting method, I don't think we should make setting the syntax tags "mandatory" by any means. People can just use a plain code block if it suits them, and I don't want to burden the translators with manually making sure the syntax tags are in there.

Thoughts?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.