Hi! I am thinking about contributing to the project. I have my own automation system. I know things are done here in ansible, but still curious if there is any niche for automation like tasks in the project?

Currently when FreeIPA domain controllers are built, the zones are populated with the domain controller issues, including reverse DNS entries. However, there are two problems with the clients:

• Their DNS servers in /etc/resolv.conf need to point at the domain controllers in their DC

  • This requires a change, potentially to role-rocky-ipa-client.yml to assert if the DNS resolver is correct and if not, change it
  • This change will also require a way to determine, based on subnet, what zone it's in to correct the above if needed
  • Kickstarts of systems can also configure the systems to be static addressed to put in another "check"

• Clients do not receive PTR records

  • A post_task should be added after the initial install to turn on automatic PTR records
  • Other domains created (reverse) should also have automatic PTR records

We should add Issue templates and PR templates to enhances the workflow of the repository.

suggestion

Slack Link

Naming Scheme

{identifier - 2 characters}{location code - 2 characters}{system type - 1 character}{server type - 1 character}{environment - 1 character}{function - 4 characters}{instance number - 3 characters}[s for service processor)
identifier:
    group / corp / etc
location code:
    where the servers are
System Type:
    s = server
    w = workstation
    n = network gear. Switch, etc.
Server Type:
    p = production
    s = staging
    t = testing
    d = development
environment:
    p = physical
    v = virtual
function:
    defines the function of the server.
    ad = Active Directory
    ns = Name Server
    edge = network edge, firewall, router, etc.
    osn = OpenStack Node
instance number:
    defines the instance number of the server, used if a service has more than
    one host or node. starts at 001, always pad with zeros.
service processor - drac, ILO, etc.

example

rlnaspvweb001.in.rockylinux.org

rl = rocky linux
na = north america
s = server
p = production
v = virtual
web = http host
001 = first instance

in = internal domain

just a starting point. 15 characters to be NetBIOS compatible, not required. The identifier field can be removed and replaced with a 4-character location field for example.

Need to start diagramming the dependencies of these applications for when they get deployed in HA.

Right now they are in docker on my server. Openproject and wiki.js are sharing a postgresql server. Separate databases. Separate users.

Will update with more in morning.

https://opendev.org/ was suggested by a user in the infra Slack, wanted to note this for discussion and review by the infra team.

Do note it is a different sort of offering from a GitLab or GitHub, being change-management driven rather than pull-driven. https://zuul-ci.org/docs/zuul/discussion/gating.html discusses some concepts around that.

although these will not be the final hostname... rockylinux.com instead of rockylinux.org is bothering me.

I would recommend Zabbix for monitoring the Infrastruture. What do you think about that idea?

This helps mitigate DNF bugs.

Hello,

It is always important to define an IP addressing plan before starting to deploy servers and network infrastructure.
I saw on the FreeIPA inventory that you were using the subnet 10.100.1.0/24.

Has this been discussed in slack, IRC or on the forums ?

I'm asking because it would be best to think about it a bit before deploying base infrastructure like IPA, firewalls and VPNs.

For example we could reserve a supernet for each geographical zone. It eases network summarization.

• Europe - 10.128.0.0/12
• Americas - 10.144.0.0/12
• Asia - 10.160.0.0/12
• etc.

And then carve subnets in them to provision services.

Let me know what you think.

Should be getting a (couple) -

32GB ECC DDR3
e3-12xx Xeon
2x128SSD boot
2x2TB data
1gbit public net
1gbit private vlan

/27 public IPv4
/64 (allocated to /48) IPv6

Site net: 10.16.0.0/20

I ran across the Infrastructure discussion on Discourse. Lots of good suggestions there for monitoring tools.

I'd like to offer a few that are used in the back end of allstarlink.org:

LibreNMS - used for monitoring servers and services. Pretty configurable and has lots of options for alerts. It can even feed its data into InfluxDB or Prometheus for use in Grafana.

Graylog - an open source SIEM that takes parts of the ELK stack and can use other things as well to ingest logs and store them in an Elasticsearch back end. Lots of options for things too like pipelines, streams, events/alerts and notifications. Can be clustered together as well easily. The community edition offers quite a few options and it has a good API to query for pulling information if you don't want to query Elasticsearch directly.

SaltStack - While Ansible is more widely known, SaltStack is a good powerful replacement that also does orchestration and has an event management feature (reactor) where a node (minion) can report back and have it kick off automation to remedy an issue.

Hope this helps.

I can work on this project. There are several in galaxy however none seem to support CentOS8

My recommendation:

• We use chrony rather then traditional NTP - https://chrony.tuxfamily.org/
  Chrony uses traditional NTP protocol but has extras to handle some worst case scenarios.
  Chrony also allows us to run chrony server on virtual machines without the root_dispersion being trash.

• We have a pair of chrony servers per site that pull from public source (ntp.org or whatever)
  Then all of hosts/clients sync to the local servers with chrony client

• Chrony is just traditional NTP so network devices will be able to sync to the servers no problem.

• We don't need to achieve stratum 0 or anything... Stratum 3 will be perfectly acceptable.

This repository (along with many of the brand-new rocky-linux group) needs a license defined and COPYING file applied before many people can start contributing to or using them. I'm not sure what is an appropriate licence (GPL? Apache? MIT?), but without one, it is both ambiguous and many corporate entities assume "all rights reserved" without a clear open source license.

Hi,
I found /var/srpmproc/srpmproc_wrapper in koji build, but there is no way to get it.

https://kojidev.rockylinux.org/kojifiles/work/tasks/1370/251370/root.log

https://koji.rockylinux.org/koji/search?terms=srpmproc*&type=rpm&match=regexp

maybe link https://distrobuildstg.rockylinux.org/internal-repo/x86_64/Packages/srpmproc-0.1.0-2.x86_64.rpm

but , oops 404...

Based on the following ticket, we are looking to enable SSO with keycloak. SAML or OIDC both work and are acceptable. The plugin will have to be in PHP as the bug tracker is built with PHP (mantis bt). There are example plugins in the mantis github but they are not maintained or poorly documented.

Creating this ticket as somewhere to discuss logging solutions as there is too much discussion of it in the monitoring ticket.

The needs are yet to be fully declined, but here are some initial thoughts:

• ELK is a very common stack. It is mature, scalable and well liked. There will be no shortage of volunteers who are comfortable with it.
• Loki/Promtail is a much newer option. It should be much lighter/cheaper as there is no need for an Elasticsearch cluster with the data stored in Object Storage (S3?). Visualisation would be via the same Grafana used for Prometheus and the query syntax is similar to PromQL.

I'm sure plenty will have an opinion here so let the games commence.

Something I've often seen teams neglect but is important for long-term maintenance and ease of collaboration is standardizing on coding and style standards, like https://google.github.io/styleguide/shellguide.html for bash scripts, making sure that people aren't writing POSIX scripts but then using a #!/bin/bash shebang, or requiring python to comply with pep8, etc

Skip Grube put together some very nice docs to be included in this repo when the team is able to review.

https://gitlab.com/SkipGrube/RockyLinux/-/blob/master/Build_Steps.md

How about three:
Intel Xeon E3v5/v6,
64GB DDR4 ECC RAM,
4 x 2TB HDD,
Hardware RAID,
1Gbps Ports,
vLan with a Subnet assigned to the vLan for you to use on the VM’s.
Complimentary DDoS Protection,
London, UK

/27 public net

Site prefix: 10.1.0.0/20

Rocky Linux will require a stable process to create resources and hand them over to ansible to be provisioned.

Ideally it would be all wrapped in a webhook to notify us when things are done.

Some ideas off the top of my head are:

• cloud-init configures ansible and runs it from the server, pulling from main ansible servers
• cloud-init configures ansible and triggers AWX to run the provisioning

Want to make sure security concerns are addressed and machines are bootstrapped immediately.

Hi, my name is Skip Grube.

There are several of us in the #rocky-devel-packaging channel on Slack that are working/thinking/prototyping about a core piece of Rocky Linux: how to get the upstream sources into a form we can use, then rebuild them.

(See: https://gitlab.com/SkipGrube/RockyLinux/-/blob/master/Build_Steps.md )

There's been a lot of discussion, some prototyping, and lots of links flying around.

We very much need a "Development" or "ReleaseEngineer" section of a Wiki somewhere that we are all allowed to contribute in. Sharing links on Slack is great, but much gets lost after one discussion ends. We're looking for somewhere permanent to dump these links/ideas, such as the .md above.

I don't much care what it's called, or where it lives, but... do we have the ability to do this? We would like to limit ourselves to just that single "folder" in the Wiki.

Thanks!
-Skip Grube

We will need playbooks that install Koji, GitLab EE, and Pagure. These will more than likely require roles to be pulled in from additional repos within rocky-linux, eg ansible-role-kojihub for example.

Pagure will likely need to be used with a messaging bus or we will need to build our own bus. The MBS communicates with both pagure and koji. GitLab does not support what Pagure/Koji/MBS do unless we make custom tooling.

With the first hardware servers getting set up, I've been playing around with kickstart and PXE to help get the first servers provisioned. It's probably a good idea to have an issue about it.

In #5 I have an initial kickstart thingy underway, and I also have some beginning of a PXE server automation in a separate branch.

The initial goal ought to be to provide just enough to get basic CentOS 8.3 hosts running so that Ansible can take over.

Since github repos have started getting content I think there should be a readme with contribution guidelines and code of conduct for newcomers in addition with what has been proposed in this post https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192 but more focused to code repos such as ansible playbooks, the landing page code etc. If you are already working on it please ignore the issue :) .

Why did you choose to split this project on multiple platforms ... GITHUB of all ... and the issues on bugzilla ? if you expect people to signup on a new platform, why not choose gitlab ? IT'S FREE

A common request we get in slack and IRC is about extra architectures, primarily ARM. A nice to have would be if after x86_64 is completed, other architectures could be part of the release process or part of Special Interest Groups who will work on or facilitate those builds. The architectures currently of interest would be:

• aarch64
• ppc64le

It is likely we will need our own altarch SIG sometime in the future. This ticket may move to a bug tracker at some point in the future.

Could we settle and document on the design of the infra

Requirements of the dev and build teams before we start creating ansible scripts and modules.
We want to do this right the first time and not free ride.
so we need consensus with the build teams that it is what they need.

Do we already have a wiki or confluence setup?
How do we make sure consensus is reached and the design for the infra is approved.
How do we assign tasks to individual contributors
how do we manage rights and credentials..
I saw some questions and comments regarding IP ranges and stuff. All valid questions, that need documenting before we deploy.

and so many other items
Happy to discuss and help

After adding local fixes, the chrony playbook has precedence issues with variables. The group_vars are overriden by the vars included, regardless of the hostgroup. Regardless of configuration as a client or server, in both instances the client and server are pointing to the NTP pool. It is also unlikely there will be a "chronyclients" host group, so we'll make the internal NTP servers the default.

This is to track the fix.

I think there should be CONTRIBUTING.md of how people should contribute to this repo.

Something I thought about (and just ran into). The %post, or something else, should have something about enabling powertools. dnf config-manager --set-enabled powertools - I've been testing my pagure role and it blew up because of missing deps... and they're in powertools. A lot of builds are likely going to require powertools regardless.

Originally posted by @nazunalika in #5 (comment)

Own issue so we can reference it during code review.