Difference between revisions of "User talk:Francoism"

From ArchWiki
Jump to: navigation, search
(AppArmor in linux-hardened edits: re)
m (AppArmor in linux-hardened edits: [mod] please...)
Line 97: Line 97:
 
::::I try to extensively comment my fixes. "Prepare for next revert" in what you linked reverts typo fix which I needed to revert first because it blocked reverting the real commit which I commented with "This is now covered in https://wiki.archlinux.org/index.php/AppArmor#Kernel which is similar to how SElinux is documented." Where is this bullying that you are talking about?
 
::::I try to extensively comment my fixes. "Prepare for next revert" in what you linked reverts typo fix which I needed to revert first because it blocked reverting the real commit which I commented with "This is now covered in https://wiki.archlinux.org/index.php/AppArmor#Kernel which is similar to how SElinux is documented." Where is this bullying that you are talking about?
 
::::On the other hand you are reverting my changes without explanation even as it fixed an obvious typo of yours: https://wiki.archlinux.org/index.php?title=Audit_framework&type=revision&diff=529019&oldid=529010
 
::::On the other hand you are reverting my changes without explanation even as it fixed an obvious typo of yours: https://wiki.archlinux.org/index.php?title=Audit_framework&type=revision&diff=529019&oldid=529010
::::What the hell {{ic|overrule.service}} is?
+
::::What {{ic|overrule.service}} is?
 
::::Do you know why I named the proposed file as {{ic|/etc/systemd/system/auditd.service.d/override.conf}} ? Because files edited with {{ic|systemctl edit service-name.conf}} are named {{ic|override.conf}} by default.
 
::::Do you know why I named the proposed file as {{ic|/etc/systemd/system/auditd.service.d/override.conf}} ? Because files edited with {{ic|systemctl edit service-name.conf}} are named {{ic|override.conf}} by default.
  

Revision as of 17:13, 8 July 2018

Splitting edits

Hey Francoism, thank you for contributing :) I wanted to talk about a couple of edits you've just made, [1] and [2]: when moving content, each move should be done in its own edit (the same edit, not cut in one and paste in another), without changing the content; only once the content is in the new place, it can be modified in a following separate edit; this is to ensure that every diff is understandable and it's always possible to determine what is the source of every piece of information.

You may be interested in reading ArchWiki:Contributing#Do_not_make_complex_edits_at_once and Help:Procedures#Move_a_section_within_the_same_page.

Another tip: you can use [[internal links]] in edit summaries, which is often very useful to point to related pages (e.g. when moving content to or from somewhere) or discussions.

Cheers — Kynikos (talk) 06:28, 9 March 2016 (UTC)

Hi Kynikos, thanks for your input. I will be moving sections as preferred from now one.
Sometimes I simple forget to click on edit in the top-navigation and simple edit the sections separately instead.
Didn't know it was possible to use internal links, will read ArchWiki:Contributing for a second time. :)
Francoism (talk) 09:48, 10 March 2016 (UTC)
Hi, thank you as always for helping looking after this wiki! I thought I'd remind you of the possibility to link to articles in edit summaries, for example it would have been useful in [3] to show that the content comes from [4] and it's not a new addition :)
Then, well, while I'm here for the sake of fairness I have to point out that splitting that move and [5] would have made it easier to understand the diffs for the users watching those pages ;)
Cheers -- Kynikos (talk) 15:36, 23 August 2017 (UTC)

Typo in your talk page link

Just wanted to let you know, there is a typo in your talk page link in ArchWiki:Maintainers. -- nl6720 (talk) 10:04, 18 October 2016 (UTC)

Thanks! Fixed. :) Francoism (talk) 10:09, 18 October 2016 (UTC)

systemd page

Why did you revert my change? I just tested, you don't need the -f to override a previously-set default target. "systemctl set-default whatever.target" will set the default regardless if it's been already set. --Chowbok (talk) 13:38, 20 March 2018 (UTC)

This should first be discussed in Talk:Systemd.
Francoism (talk) 15:36, 20 March 2018 (UTC)
This wouldn't be necessary if you at least tried it before hitting a button. If you can't think of a good reason to revert an edit, don't. -- Lahwaacz (talk) 17:44, 20 March 2018 (UTC)
@Chowbok and @Lahwaacz: Sorry for the revert! I thought the force overwrite flag was necessary to overrule the init level.
Francoism (talk) 18:09, 20 March 2018 (UTC)

NVIDIA page - crash on autogenerating xconfig using GDM

Hello! You've asked for reference in order to approve my edit. Should I post a topic on the forums with my issue and give that as reference? Opptur (talk) 16:34, 1 May 2018 (UTC)

Please sign your comments. :)
It may be a bug, if not reported already, report upstream.
Good idea to first ask on the forums thought.
Francoism (talk) 16:31, 1 May 2018 (UTC)
Sorry, I didn't pay attention to the header in this page. I have created a bug report here [6].
Opptur (talk) 18:00, 1 May 2018 (UTC)
Doesn't seem to be a bug thought, this is the reason why no (auto-)generated Xorg config are being created anymore.
You should simple create a /etc/X11/xorg.conf.d/10-monitor.conf and/or /etc/X11/xorg.conf.d/20-nvidia.conf if you want to overrule settings, see Xorg and NVIDIA. Also consider asking the forum for help. Good luck!
Francoism (talk) 19:09, 2 May 2018 (UTC)

AMD DC

Hi Francoism,

You recently added instructions for how to enable AMD DC at AMDGPU, but according to this Phoronix article, it should be enabled by default. Do you know if that article is incorrect?

Also, we refer to Sea Islands (CIK) as GCN2 at Xorg#AMD as does Wikipedia at w:Graphics Core Next. AMD has indeed previously called it GCN1.1, but I think we should keep our usage consistent.

Lonaowna (talk) 19:02, 28 June 2018 (UTC)

Hi Lonaowna,
I am also confused about this, is this logged in dmesg and/or any other file?
Thanks for the suggestion! I was confused about GCN1/GCN1.1 thing, so I agree this is a better option.
Francoism (talk) 09:17, 29 June 2018 (UTC)
I'm not sure how to test it; I don't have an AMD GPU myself. Looking at the source code, it seems that by default DC is used by default for CHIP_HAWAII (=GCN2/CIK) and newer, and can be enabled with the amdgpu.dc option for CHIP_BONAIRE,CHIP_KAVERI,CHIP_KABINI and CHIP_MULLINS. I don't know which cards that are, but it seems that the switch is not needed for Hawaii and newer.
Lonaowna (talk) 17:21, 29 June 2018 (UTC)

AppArmor in linux-hardened edits

While editing my change https://wiki.archlinux.org/index.php?title=AppArmor&type=revision&diff=528922&oldid=528914 you deleted important information:

In linux-hardened providing apparmor=1 security=apparmor boot params is mandatory while in linux-apparmorAUR it isn't. After your edit it appears there is no difference between those two.

Secondly linux-hardened hardcodes audit=0 boot param which is unique behavior documented only in Audit_framework wiki page thus linking to it is another important information which you deleted.

Please bring those back and pay attention to the details. Teples (talk) 12:24, 6 July 2018 (UTC)

Hi Teples, thanks for your contributions and details.
It all depends on the user's configuration (custom kernel and/or provided kernel) and one can easily check if AppArmor has been successful enabled. It does not make much sense to mention it twice. Information about this kernel should be added to linux-hardened instead.
The Audit framework page already provides information about the linux-hardened audit flag and it should not be enabled by default either.
Francoism (talk) 12:49, 6 July 2018 (UTC)
The purpose of the wiki is to provide relevant information to uninformed users especially Archlinux specific information. Saying that "one can easily check" render the whole wiki page obsolete and redundant.
The second mention of boot params refers to compiling own kernel and says "Alternatively" which is obviously wrong in linux-hardened case. That's the one you may delete instead.
linux-hardened isn't a place for mentioning AppArmor. SElinux isn't mentioned there even as it was enabled from the beginning.
Enabling Audit is critical for AppArmor usage, that's why it should be linked there.
Teples (talk) 17:11, 6 July 2018 (UTC)
Could you tell me why the Audit should be enabled by default? My understanding is that this is only needed to create and debug profiles.
It's not wrong, it tells you how to enable AppArmor. With your latest edit it seems this only applies to linux-hardened, but this could also be relevant for other/custom kernels as-well.
I don't like edit comments like this one: https://wiki.archlinux.org/index.php?title=Security&oldid=528998
We all want to help users by providing a good and helpful Wiki, not bullying users.
Francoism (talk) 19:01, 6 July 2018 (UTC)
It told you about "alternative". For linux-hardened it isn't alternative it's necessary. You deleted that information. It wasn't necessary for provided KCONFIGS for custom kernels. That's the difference.
Audit is necessary because without it user can't say what AppArmor really does on their system. Keep in mind that profiles provided in apparmor userspace tools aren't much tested on Archlinux, I have dozens of local fixes myself.
I try to extensively comment my fixes. "Prepare for next revert" in what you linked reverts typo fix which I needed to revert first because it blocked reverting the real commit which I commented with "This is now covered in https://wiki.archlinux.org/index.php/AppArmor#Kernel which is similar to how SElinux is documented." Where is this bullying that you are talking about?
On the other hand you are reverting my changes without explanation even as it fixed an obvious typo of yours: https://wiki.archlinux.org/index.php?title=Audit_framework&type=revision&diff=529019&oldid=529010
What overrule.service is?
Do you know why I named the proposed file as /etc/systemd/system/auditd.service.d/override.conf ? Because files edited with systemctl edit service-name.conf are named override.conf by default.
As I already wrote you don't pay attention to details and I don't believe careless reverting my changes is helpful to anyone. Please think about it.
Teples (talk) 21:37, 6 July 2018 (UTC)
Audit really has an impact on the system resources and so far I cannot find any reference upstream that this should be enabled/be recommended for AppArmor to function and/or should be needed for most users.
My understanding is that this only should be used when debugging (e.g. creating, testing, etc.) profiles (that seems to the example you're giving and is already described in this section: AppArmor#Auditing_and_generating_profiles).
Your reverts are not done to fix typo's, it's just to replace the same edit you have posted before with, again, no upstream examples and/or other reference(s).
I agree about overrule.conf (and yes, I do know how systemd works), but again, do not revert a whole section just because you want to 'fix a typo'; provide a better name instead.
The article is about AppArmor and not in particular Linux-hardend , use a note and/or other clean solution for details about this kernel instead.
Finally, next time please don't start reverting sections, simple use the talk page from the article instead and I'm sure other Wiki maintainers and users will give you feedback.
On final note to myself: Use the talk page to give user feedback.
Francoism (talk) 09:03, 7 July 2018 (UTC)
Audit impact on resources is negligible especially after fast path was deleted due to meltdown fixes. Creating and editing profiles it's essential thing to do while using AppArmor. Normally Audit is automatically enabled while using MAC in Linux kernel - you can check in other distros like Ubuntu, Debian or OpenSuse. That's why there is no need to explicitly recommend it. Linux-hardened is different, it hardcodes audit=0 in cmdline which has to be overridden manually when enabling MAC like SElinux or AppArmor. No other packaged or build from source kernel has this feature. Everywhere else enabling AppArmor enables Audit as well. Do you understand now why it's important to note this behavior in wiki?
You linked to typo revert and called it "bullying". maybe you wanted to link to something else I don't know. My every change is explicitly commented, please tell me which comment you don't like. I reverted your change which introduced obvious mistakes like overrule.conf and you brought it back. It's still there even as you know about it. You didn't provide any upstream examples and/or other reference, just introduced a typo in a work of mine.
This is Archlinux wiki and Linux-hardened is the only Archlinux package supporting AppArmor that's why it should be documented first. I added note about it: https://wiki.archlinux.org/index.php?title=AppArmor&type=revision&diff=528914&oldid=522888 which was deleted by you https://wiki.archlinux.org/index.php?title=AppArmor&type=revision&diff=528922&oldid=528914 and now you tell me "use a note and/or other clean solution for details about this kernel instead". Can you explain what do you have in mind here?
I posted here because the issue is not about AppArmor/Audit or linux-hardened but your behavior which I found problematic. You didn't use the 'talk' page yourself and just deleted my changes. I tried to do my best to extensively explain my reasoning but I don't feel you really care.
Teples (talk) 13:28, 7 July 2018 (UTC)