default/linux/amd64/17.1/hardened
which has a minimal set of predefined USE flags, hence why /etc/portage is so extensively populated by us. It allows a "fine tuning".
Some other profiles like may enforce some USE flags such as:
default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr
which will enforce systemd and plasma related USE flags
Systemd and related USE flags are masked in Redcore Linux for example. So if you want to Redcore-ify Gentoo, you need to start small and build your way up. Hence why my initial suggestion of just removing Sisyphus is a simpler approach.
A complete list of profiles can be obtained using :
eselect profile list
rc-update del apparmor boot
Followed by a reboot will disable it. However a better approach will be to fine tune it to your preferences.
For example :
aa-status
will return something like this:
apparmor module is loaded.
60 profiles are loaded.
60 profiles are in enforce mode.
/usr/bin/akonadiserver
/usr/lib/apache2/mpm-prefork/apache2
/usr/lib/apache2/mpm-prefork/apache2//DEFAULT_URI
/usr/lib/apache2/mpm-prefork/apache2//HANDLING_UNTRUSTED_INPUT
/usr/lib/apache2/mpm-prefork/apache2//phpsysinfo
apache2
apache2//DEFAULT_URI
apache2//HANDLING_UNTRUSTED_INPUT
apache2//phpsysinfo
avahi-daemon
dnsmasq
dnsmasq//libvirt_leaseshelper
dovecot
dovecot-anvil
dovecot-auth
dovecot-config
dovecot-deliver
dovecot-dict
dovecot-director
dovecot-doveadm-server
dovecot-dovecot-auth
dovecot-dovecot-lda
dovecot-dovecot-lda//sendmail
dovecot-imap
dovecot-imap-login
dovecot-lmtp
dovecot-log
dovecot-managesieve
dovecot-managesieve-login
dovecot-pop3
dovecot-pop3-login
dovecot-replicator
dovecot-script-login
dovecot-ssl-params
dovecot-stats
identd
klogd
lsb_release
mariadbd_akonadi
mdnsd
mysqld_akonadi
nscd
ntpd
nvidia_modprobe
nvidia_modprobe//kmod
php-fpm
ping
postgresql_akonadi
samba-bgqd
samba-dcerpcd
samba-rpcd
samba-rpcd-classic
samba-rpcd-spoolss
smbldap-useradd
smbldap-useradd///etc/init.d/nscd
syslogd
traceroute
zgrep
zgrep//helper
zgrep//sed
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
2 processes have profiles defined.
2 processes are in enforce mode.
/usr/sbin/avahi-daemon (4418) avahi-daemon
/usr/sbin/avahi-daemon (4419) avahi-daemon
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
Then you can disable a certain program or profile like this :
aa-disable syslogd
Apparmor is almost unnoticeable at runtime and proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good behavior and preventing both known and unknown application flaws from being exploited. It is up to you if you're willing to take the risks or not.
]]>P.S. When the kernel gets updated, you just need to reboot, and dkms will recompile the modules for the new kernel.
]]>gpasswd -a your_username deluge
Followed by a logout-login cycle *should* sort it.
]]>Source package(s) found in the mix!
Use 'sisyphus upgrade --ebuild'
red /opt/redcore-build #
this works but sisyphus not upgrade yet. source packages masked...
]]>I have noticed that the distribution does not include "sudo" or "doas" by default. While this design choice aligns with Redcore Linux's specific goals and principles, I believe that introducing "doas" could greatly benefit both new and experienced users.
The Advantages of Implementing doas:
1. Enhanced Usability:
-User-Friendly Administrative Access:
"doas" allows regular users to perform administrative tasks with a clear and user-friendly syntax. This would make Redcore Linux more accessible to a wider audience, including those who might be new to Linux.
- Simplified Command Execution:With
"doas," users can execute individual commands with elevated privileges without needing to switch to a root shell. This streamlined approach reduces the risk of accidental system modifications.
2. Improved Security:
- Fine-Grained Control:
"doas" provides fine-grained control over which users or groups can execute specific commands as root. This aligns with the principle of least privilege, limiting potential security risks.
- Auditing and Logging:
"doas" offers auditing and logging capabilities, allowing administrators to track and review commands executed with elevated privileges. This enhances security and accountability.
3. Compatibility and Documentation:
-Widely Adopted Standard:
"doas" is increasingly becoming a standard tool in Unix-like operating systems. Its use is widely documented, making it easier for users to find resources and support.
-Consistency with Linux Ecosystem:
Many Linux distributions include "sudo" or "doas" as part of their standard toolset. Adopting "doas" in Redcore Linux would align it more closely with the broader Linux ecosystem.
I would like to propose consider implementing "doas" as an optional utility that users can choose to install during the initial setup or afterward. This approach allows users to maintain the distribution's minimalist philosophy while also accommodating those who prefer or require the features and usability benefits of "doas."
I understand that this suggestion may require careful consideration and testing to ensure it aligns with Redcore Linux's goals and principles. However, I believe that offering "doas" as an option would make Redcore Linux even more appealing to a diverse user base, including casual users who seek a user-friendly Linux distribution.
Thank you for your time and consideration. I look forward to your feedback on this suggestion and would be happy to assist with any further discussions or testing if needed.
]]>