There is (IMO) some overlap between the Admin guide and the Desktop one and there will always be so with that thought should we transfer some topics across?

On Fri, 2007-12-07 at 16:18 -0800, Karsten Wade wrote: > On Fri, 2007-12-07 at 23:22 +0900, Marc Wiriadisastra wrote: >> There is (IMO) some overlap between the >> Admin guide and the Desktop one and there will always be so with that >> thought should we transfer some topics across? > What is the overlap you see? > > - Karsten Yum and user administration I would think? Since there is/was system-config-users which is the gui side but it's possibly an admin tool.

Samba for file sharing. There are gui tools as well but setting up the config. Associated selinux details.

I'm picking stuff that I consider to be important to the average desktop at the moment :) Cheers, Marc

On Sat, 2007-12-08 at 14:09 +1300, Vladimir Kosovac wrote: > > Marc Wiriadisastra wrote: > > On Fri, 2007-12-07 at 16:18 -0800, Karsten Wade wrote: > >> On Fri, 2007-12-07 at 23:22 +0900, Marc Wiriadisastra wrote: > >>> There is (IMO) some overlap between the > >>> Admin guide and the Desktop one and there will always be so with that > >>> thought should we transfer some topics across? > >> What is the overlap you see? > >> > >> - Karsten > > > > Yum and user administration I would think? > > > > Since there is/was system-config-users which is the gui side but it's > > possibly an admin tool. > > I don't think this stuff is out-of-place in a DUG. To teach people new > to Fedora how to use PC effectively, basic system administration should > be included. Probably just a matter of figuring the right amount of > information. John posted earlier with reasons why these subjects all belong in the Administration Guide, not the DUG. If someone needs to "administer" their system to make basic use of it, that's a *bug*. Whether a tool is GUI or not has no bearing on it being included in one guide or another; in fact, a good case could be made that almost *nothing* non-GUI should be in the Desktop User Guide. The AG should, in fact, prefer GUI tools to hand-editing configuration files whenever possible. This is part of the "best practices" for which we should shoot. Where the GUI tools are deficient, the basic use cases should be the first covered, using the GUI tools, and the more advanced or infrequent use cases requiring other admin interactions should follow.

On Sat, 2007-12-08 at 14:34 +0900, Marc Wiriadisastra wrote: > On Fri, 2007-12-07 at 21:20 -0500, Paul W. Frields wrote: > > On Sat, 2007-12-08 at 14:09 +1300, Vladimir Kosovac wrote: > > > > > > Marc Wiriadisastra wrote: > > > > On Fri, 2007-12-07 at 16:18 -0800, Karsten Wade wrote: > > > >> On Fri, 2007-12-07 at 23:22 +0900, Marc Wiriadisastra wrote: > > > >>> There is (IMO) some overlap between the > > > >>> Admin guide and the Desktop one and there will always be so with that > > > >>> thought should we transfer some topics across? > > > >> What is the overlap you see? > > > >> > > > >> - Karsten > > > > > > > > Yum and user administration I would think? > > > > > > > > Since there is/was system-config-users which is the gui side but it's > > > > possibly an admin tool. > > > > > > I don't think this stuff is out-of-place in a DUG. To teach people new > > > to Fedora how to use PC effectively, basic system administration should > > > be included. Probably just a matter of figuring the right amount of > > > information. > > > > John posted earlier with reasons why these subjects all belong in the > > Administration Guide, not the DUG. If someone needs to "administer" > > their system to make basic use of it, that's a *bug*. Whether a tool is > > GUI or not has no bearing on it being included in one guide or another; > > in fact, a good case could be made that almost *nothing* non-GUI should > > be in the Desktop User Guide. > > > > The AG should, in fact, prefer GUI tools to hand-editing configuration > > files whenever possible. This is part of the "best practices" for which > > we should shoot. Where the GUI tools are deficient, the basic use cases > > should be the first covered, using the GUI tools, and the more advanced > > or infrequent use cases requiring other admin interactions should > > follow. > > The question then is why yum should not be covered in the DUG. An > example use case: You have yum-updatesd and to update you need to > disable the cdrom update since it won't find it. Those are all gui > tools and are part of yum. Does installing from a DVD automatically enable the DVD as a repo? I honestly don't know, since I haven't used a DVD to install in a very long time. The act of updating a system is one area I would say deserves attention in the DUG and the AG. That area of overlap, to me, would be understandable.

> You need to set up file-sharing which I would call desktop capability a > server set up would be an administration part. I'm not trying to be > pedantic but maybe my definition of desktop to administrator is > different. Setting up file sharing in the DUG is using System -> Preferences -> Network -> Personal File Sharing. Anything beyond that is AG material.

> Desktop is everything a desktop user would require including samba, yum, > desktop sharing etc. As far as Samba goes, all a DUG audience member does is Places -> Network. Beyond that is AG material. > Administration network login, advanced samba, advanced yum such as > setting up local repo's etc. The advanced stuff. Sure, these are all use cases for the AG. > Am I off on my own? If so can I have some guidance so I don't add stuff > that is technically not considered appropriate for a desktop user? That's exactly what this list and this discussion are for, and I for one sincerely applaud you for using it. A lot of people are driven to handle all of this stuff on IRC, which is really a very poor choice for discussion that you want to filter out to the larger community. We love talking on IRC and I think it's a great place for quick help or to discover new issues, but to really get the issues pinned down with details requires thoughtful discussion, and the mailing list is best for that. Again, and in all sincerity, thank you for continuing this dialogue!

On Sat, 2007-12-08 at 14:54 +0900, Marc Wiriadisastra wrote:

> I've got a lot of questions like this which is the essence of the > original email. Can we put together a list of what topics should be > covered and to what limits each category should move to. Then we have a > target to move towards? Unfortunately I don't have the cycles to do it, but you are welcome and encouraged to start such a list, and float it to the mailing list for discussion. I think that's a very thoughtful process, and I'm sure others will pitch in their ideas.

Paul W. Frields wrote: > On Sat, 2007-12-08 at 14:54 +0900, Marc Wiriadisastra wrote: > >>> Does installing from a DVD automatically enable the DVD as a repo? I >>> honestly don't know, since I haven't used a DVD to install in a very >>> long time. The act of updating a system is one area I would say >>> deserves attention in the DUG and the AG. That area of overlap, to me, >>> would be understandable. >>> >>> >> I would assume it does since on the fedoraforum there was a severe >> amount of complaints about having to put a cd/dvd. >> > Before documenting it, whoever is writing that section should definitely > confirm the behavior first. > I've tried two different installs - DVD and http, in both cases install source ends up on the list of pre-selected repositories. If DVD install is used and DVD not inserted post-install, pup and pirut fail until ''install media"" repo is de-selected. Vladimir

>> The purpose of it is a feature since you can now upgrade the fedora version >> using yum and a dvd which is a huge plus. The problem arises is that the >> cd/dvd repo itself is usually enabled by default after this. >> >> An update fails because it can't find the cd/dvd repo since your cd/dvd >> is not in the drive so it can't find it so the update fails. >> That is possibly a bug however I'm not sure of the status of that bug or >> even if it is considered a bug. >> >> The simplest method to fix it is disabling the repo and then voila >> yum-updatesd works by default updating the software. >> >> I hope thats clear because I personally have never experienced it >> since I've always just used yum upgrade and edited the config files manually. >> > It is clear, but editing the configuration files manually is not the > appropriate solution for the DUG. Instead, the documentation should > indicate how the desktop user can use the Edit Repositories option in > pup and pirut. Again, focus on ease of use and GUI desktop usage > wherever possible. >

>>>> You need to set up file-sharing which I would call desktop capability a >>>> server set up would be an administration part. I'm not trying to be >>>> pedantic but maybe my definition of desktop to administrator is >>>> different. >>>> >>> Setting up file sharing in the DUG is using System -> Preferences -> >>> Network -> Personal File Sharing. Anything beyond that is AG material. >>> >>> >> Has anyone got that to work? I've never actually got it to function >> properly. >> > It works if the firewall is disabled. This is not ideal, and I would > call this a bug unless both of us are doing something very wrong. I > thought one of the points of ConsoleKit was to be able to punch a hole > in the firewall for personal files sharing. In the meantime, I would > simply document the behavior indicating that the user should consult the > AG for firewall configuration info. > >

>> I've got a lot of questions like this which is the essence of the >> original email. Can we put together a list of what topics should be >> covered and to what limits each category should move to. Then we have a >> target to move towards? >> > Unfortunately I don't have the cycles to do it, but you are welcome and > encouraged to start such a list, and float it to the mailing list for > discussion. I think that's a very thoughtful process, and I'm sure > others will pitch in their ideas. > > >

Dan O'Brien wrote: > Vladimir Kosovac wrote: > >> Paul W. Frields wrote: >> >> >>> On Sat, 2007-12-08 at 14:54 +0900, Marc Wiriadisastra wrote: >>> >>> >>>>> Does installing from a DVD automatically enable the DVD as a repo? I >>>>> honestly don't know, since I haven't used a DVD to install in a very >>>>> long time. The act of updating a system is one area I would say >>>>> deserves attention in the DUG and the AG. That area of overlap, to me, >>>>> would be understandable. >>>>> >>>>> >>>>> >>>> I would assume it does since on the fedoraforum there was a severe >>>> amount of complaints about having to put a cd/dvd. >>>> >>>> >>> Before documenting it, whoever is writing that section should definitely >>> confirm the behavior first. >>> >>> >> I've tried two different installs - DVD and http, in both cases install >> source ends up on the list of pre-selected repositories. If DVD install >> is used and DVD not inserted post-install, pup and pirut fail until >> ''install media"" repo is de-selected. >> >> Vladimir >> >> > This didn't used to be the behavior of a fedora install, but (afaik) it > has been like this since F7. > > For things like this maybe it would be worth having a common problems > section in the DUG? > Most of us here have installed Linux, weather it be Fedora or another > Linux distribution, more > times than we can count. But the DUG is geared towards people that may > have never installed it, > and may not know how to disable a repo. In any event we really should > have a section to help people > solve these issues. > >>>> The purpose of it is a feature since you can now upgrade the fedora version >>>> using yum and a dvd which is a huge plus. The problem arises is that the >>>> cd/dvd repo itself is usually enabled by default after this. >>>> >>>> An update fails because it can't find the cd/dvd repo since your cd/dvd >>>> is not in the drive so it can't find it so the update fails. >>>> That is possibly a bug however I'm not sure of the status of that bug or >>>> even if it is considered a bug. >>>> >>>> The simplest method to fix it is disabling the repo and then voila >>>> yum-updatesd works by default updating the software. >>>> >>>> I hope thats clear because I personally have never experienced it >>>> since I've always just used yum upgrade and edited the config files manually. >>>> >>>> >>> It is clear, but editing the configuration files manually is not the >>> appropriate solution for the DUG. Instead, the documentation should >>> indicate how the desktop user can use the Edit Repositories option in >>> pup and pirut. Again, focus on ease of use and GUI desktop usage >>> wherever possible. >>> >>> > Using the situation above (the one Vladimir mentioned about needing the > install media) as an example, > pup and pirut won't start until you insert the install media, so you > can't use them to disable a repo. While I > do agree that the primary focus should be on using GUI tools to solve > problems, sometimes it is necessary > to use the CLI. > This one is actually 'fixable' through GUI: Open Applications-->Add/Remove Software If the repo is not available, pirut will fail but will also present the dialogue box [1]. Click the ''Repository Manager'' button. This opens ''Repository Manager'' [2], where the repository can be enabled/disabled. I am not sure who will write this stuff and where is it supposed to be. Example [1] and [2] screenshots are here: http://fedoraproject.org/wiki/VladimirKosovac/RepoManager /!\ Note, [1] and [2] are not to be used for DUG - they don't look like defaults. Vladimir

>>>>>> You need to set up file-sharing which I would call desktop capability a >>>>>> server set up would be an administration part. I'm not trying to be >>>>>> pedantic but maybe my definition of desktop to administrator is >>>>>> different. >>>>>> >>>>>> >>>>> Setting up file sharing in the DUG is using System -> Preferences -> >>>>> Network -> Personal File Sharing. Anything beyond that is AG material. >>>>> >>>>> >>>>> >>>> Has anyone got that to work? I've never actually got it to function >>>> properly. >>>> >>>> >>> It works if the firewall is disabled. This is not ideal, and I would >>> call this a bug unless both of us are doing something very wrong. I >>> thought one of the points of ConsoleKit was to be able to punch a hole >>> in the firewall for personal files sharing. In the meantime, I would >>> simply document the behavior indicating that the user should consult the >>> AG for firewall configuration info. >>> >>> >>> > Maybe an introduction to using system-config-firewall isn't such a > stretch for the DUG. We > don't necessarily need to go into detail, but at least giving a quick > overview on how to do it > would be sufficient for most desktop users. > >>>> I've got a lot of questions like this which is the essence of the >>>> original email. Can we put together a list of what topics should be >>>> covered and to what limits each category should move to. Then we have a >>>> target to move towards? >>>> >>>> >>> Unfortunately I don't have the cycles to do it, but you are welcome and >>> encouraged to start such a list, and float it to the mailing list for >>> discussion. I think that's a very thoughtful process, and I'm sure >>> others will pitch in their ideas. >>> >>> >>> >>> >> >>