rocky-linux / infrastructure Goto Github PK
View Code? Open in Web Editor NEWThe infrastructure monorepo for the Rocky Linux project. This project will be archived/deprecated in the future.
Home Page: https://rockylinux.org
The infrastructure monorepo for the Rocky Linux project. This project will be archived/deprecated in the future.
Home Page: https://rockylinux.org
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.
And then carve subnets in them to provision services.
Let me know what you think.
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 :) .
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?
although these will not be the final hostname... rockylinux.com instead of rockylinux.org is bothering me.
We should add Issue templates and PR templates to enhances the workflow of the repository.
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.
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
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.
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:
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.
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.
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.
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.
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 would recommend Zabbix for monitoring the Infrastruture. What do you think about that idea?
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
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:
Want to make sure security concerns are addressed and machines are bootstrapped immediately.
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
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:
I'm sure plenty will have an opinion here so let the games commence.
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.
I think there should be CONTRIBUTING.md of how people should contribute to this repo.
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
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
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
role-rocky-ipa-client.yml
to assert if the DNS resolver is correct and if not, change itClients do not receive PTR records
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...
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
{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.
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.
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.
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.
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.
This helps mitigate DNF bugs.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.