[parent not found: <1152306806.7439.4.camel@localhost>]
* Re: How to make KDE default windows manager?
2006-07-07 18:10 How to make KDE default windows manager? Jesse
[not found] ` <1152306806.7439.4.camel@localhost>
@ 2006-07-09 20:43 ` cr
2006-07-12 17:38 ` transfer OS from failing HD questions James Miller
2006-08-10 19:07 ` smtp vs sendmail query James Miller
3 siblings, 0 replies; 8+ messages in thread
From: cr @ 2006-07-09 20:43 UTC (permalink / raw)
To: linux-newbie
On Sat, 08 Jul 2006 06:10, Jesse wrote:
> I installed kde using the apt-get utility, however, I want to run it as my
> default windows manager. How do I do that? I'm using Debian Linux, and
> right now, it comes up to a log in screen where I can choose IceWM, Gnome,
> and some others as my windows manager, but KDE is not one of those. Any
> ideas?
>
> Thanks,
> Jesse
I don't know the whole answer but I can maybe tell you where to look.
I assume you're using Debian Sarge with a graphical login? (The screen that
comes up with a box to enter passwords & stuff)
(I'm using Sarge / Gnome but without the graphical login)
You may need to do some fiddling on the command line - as always, save all the
bits (by renaming them to <filename.old> before you change anything) so you
can get back. There are three files that apply, I think:
The following links apply by default:
1. /etc/alternatives/x-session-manager -> /usr/bin/gnome-session
2. /etc/alternatives/x-window-manager -> /usr/bin/metacity
3. /etc/X11/default-display-manager is a file that says /usr/bin/gdm -
this sets the graphical login. Replace it with a blank file for text-only
login, or I guess there's a kde login equivalent (IIRC it used to be called
kdm in Woody, but there doesn't seem to be a /usr/bin/kdm in Sarge).
You can always just do a text login and type 'startx' to start up the GUI, in
fact that's not a bad idea, if something in the GUI seriously doesn't work
you can drop back to the command line and put it back the way it was.
Then when (if) it all works, reinstate the graphical login.
In /usr/bin, ls kd* shows a lot of kde-related files, some of which will
be the ones you need.
1. If you change the link for x-session-manager to point to startkde as
follows:
In /etc/alternatives:
ln -s /usr/bin/startkde x-session-manager
2. I'm not sure which of the many /usr/bin/kd* files you need to link
from /etc/alternatives/x-window-manager, maybe some Googling around the KDE
webpages might help.
As I said, I don't run KDE, but the above procedures (changing those three
links/files) works fine for me when swapping between Gnome and Windowmaker.
Disclaimer: I'm absolutely not an expert on Debian, even less on KDE. Hope
this gives you a start.
HTH
cr
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 8+ messages in thread* transfer OS from failing HD questions
2006-07-07 18:10 How to make KDE default windows manager? Jesse
[not found] ` <1152306806.7439.4.camel@localhost>
2006-07-09 20:43 ` cr
@ 2006-07-12 17:38 ` James Miller
2006-07-12 18:21 ` Ray Olszewski
2006-08-10 19:07 ` smtp vs sendmail query James Miller
3 siblings, 1 reply; 8+ messages in thread
From: James Miller @ 2006-07-12 17:38 UTC (permalink / raw)
To: linux-newbie
Here's a question I see as alot more newbie-oriented than memory
functions, (m)allocs and the like. I recently had strong indications that
my HD was failing in my Ubuntu (Debian variant: or is Debian now an Ubuntu
variant?) machine. Pondering over what to do about saving data from that
machine and having to do the minimal amount of reinstallation, I came up
with the following, seemingly quite precarious plan: I would get a new HD,
do a fresh install of Ubuntu to it, then stick the old drive in as slave,
boot from a rescue CD, and copy the entire contents of the old drive to
the new one, replacing any files on the new one that have the same name as
those on the old one. Both the new install and the installation on the old
HD were the same Ubuntu release, btw. Yes, it looks like a real
kludge--not pretty, and maybe not even effective. It took a really long
time. The new Ubuntu install was over in about 20 minutes--the smoothest
part of the undertaking. Transferring the 70 GB of data from the old drive
to the new one took many hours. I was getting pretty poor drive access
rates for one thing, maybe due to the fact that the old drive is on its
way out. Then, I would occasionally get I/O errors on the old drive where
a file couldn't transfer. The more of those I got, the more sure I was
that this approach wouldn't work in the end. But when I finally finished
copying over everything, guess what? The system booted right up. It looked
and acted just like the system did when the old HD was functioning
properly. I have yet to run into any system glitches, but I've only been
running it for a couple of days now. On to my questions.
1) What sort of problems might I expect to crop up as I continue to use
this system? Doubtless some binaries or other types of system files were
among the ones that wouldn't transfer because of I/O errors. 2) What other
approach might I have taken to essentially preserve the existing
installation (both configuration and data) on a new HD?
Input will be appreciated.
Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: transfer OS from failing HD questions
2006-07-12 17:38 ` transfer OS from failing HD questions James Miller
@ 2006-07-12 18:21 ` Ray Olszewski
0 siblings, 0 replies; 8+ messages in thread
From: Ray Olszewski @ 2006-07-12 18:21 UTC (permalink / raw)
To: linux-newbie
James Miller wrote:
> Here's a question I see as alot more newbie-oriented than memory
> functions, (m)allocs and the like. I recently had strong indications
> that my HD was failing in my Ubuntu (Debian variant: or is Debian now an
> Ubuntu variant?) machine. Pondering over what to do about saving data
> from that machine and having to do the minimal amount of reinstallation,
> I came up with the following, seemingly quite precarious plan: I would
> get a new HD, do a fresh install of Ubuntu to it, then stick the old
> drive in as slave, boot from a rescue CD, and copy the entire contents
> of the old drive to the new one, replacing any files on the new one that
> have the same name as those on the old one. Both the new install and the
> installation on the old HD were the same Ubuntu release, btw. Yes, it
> looks like a real kludge--not pretty, and maybe not even effective. It
> took a really long time. The new Ubuntu install was over in about 20
> minutes--the smoothest part of the undertaking. Transferring the 70 GB
> of data from the old drive to the new one took many hours. I was getting
> pretty poor drive access rates for one thing, maybe due to the fact that
> the old drive is on its way out. Then, I would occasionally get I/O
> errors on the old drive where a file couldn't transfer. The more of
> those I got, the more sure I was that this approach wouldn't work in the
> end. But when I finally finished copying over everything, guess what?
> The system booted right up. It looked and acted just like the system did
> when the old HD was functioning properly. I have yet to run into any
> system glitches, but I've only been running it for a couple of days now.
> On to my questions.
>
> 1) What sort of problems might I expect to crop up as I continue to use
> this system? Doubtless some binaries or other types of system files were
> among the ones that wouldn't transfer because of I/O errors. 2) What
> other approach might I have taken to essentially preserve the existing
> installation (both configuration and data) on a new HD?
>
> Input will be appreciated.
This is pretty close to what I've done on my Debian (usually Sid,
sometimes Sarge) systems. But I haven't had a failure of a root
filesystem in ages, so I may be forgetting some of the details.
(Transferring any filesystem other than root is, of course, trivial,
unless you use a distro that does that convoluted partitioning into
separate partitions for /usr, /tmp, and I-forget-what-all-else.)
A couple of tweaks that might improve the process:
1. Make sure DMA is on for both drives. Use hdparm to do this.
2. Installing the old drive as secondary master, instead of primary
slave, should give you slightly better transfer rates.
3. You don't actually need a rescue disk to do this; you can boot from
the new primary master. You just want to be sure not to cp over a few
directories ... /proc, /tmp, /var/log, maybe a couple of others I'm not
thinking of ... probably some odds and ends in /etc ... from the old
drive. Maybe the rescue-disk approach is simpler after all.
My usual practice these days is to set up my primary drive with separate
partitions for root (/), /boot, and /home. Then if the drive with my
root partition does fail, I just do a fresh, complete reinstall to a new
drive, and only transfer over /boot (unless I decide to compile &/or
install a new kernel), /home, and the small number of files I've
customized from the install in (for example) /etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 8+ messages in thread
* smtp vs sendmail query
2006-07-07 18:10 How to make KDE default windows manager? Jesse
` (2 preceding siblings ...)
2006-07-12 17:38 ` transfer OS from failing HD questions James Miller
@ 2006-08-10 19:07 ` James Miller
2006-08-10 19:55 ` Ray Olszewski
3 siblings, 1 reply; 8+ messages in thread
From: James Miller @ 2006-08-10 19:07 UTC (permalink / raw)
To: linux-newbie
I think I'm finally ready to abandon Pine as my e-mail client and to start
using Mutt. I thought of doing this a few years ago, but looking over Mutt
documentation and config files left me bewildered. I'm sure I will still
be confused about some of the program's workings, but it seems, after 4
years or so of using and admin'ing my Linux system(s), I have good enough
grasp of the program's basics and related e-mail workings now that I'm
ready to give it a serious go. This switch is also partly precipitated by
certain ways in which Pine has been failing me. Despite what I've said
above, the present message is not a Mutt-specific query: I'll probably be
directing those to the Mutt user list. What I'm wondering about is
something more fundamental about e-mail technology.
One of the things that kept me from using Mutt previously was the fact
that it does not do smtp, but rather apparently relies on other programs
such as sendmail for passing mail to servers that in turn pass it to other
servers and eventually to recipients. I don't care how stupid I might
sound to the initiated in saying this, but for the technically-challenged
such as myself, having an extra layer of program activity between the
e-mail client and the outgoing server is confusing: it's just another set
of configuration files to edit and keep current, and another place to look
for errors should problems arise. At the same time, I suppose there are
good reasons for having a separate program to do mail passing to outgoing
servers. The most sensible reason I can think of is that e-mailing is
often done in an institutional environment, one that has a machine on its
network dedicated to mailing functions. I have no experience of working in
such an environment, so I'm guessing at this, but that seems like it could
provide a sensible explanation for the separation between e-mail client
and outgoing mail server.
Anyway, Pine does do smtp: you enter info about your smtp server in its
config file, and away you go with sending out your mail. Mutt, as I
understand it "will never do smtp" (quotation from a Mutt information site
I haven't checked for a couple years but which I assume to reflect the
current state of affairs). I will thus, I assume, need to look into
getting and setting up a program to interact with the smtp server I will
be sending mail through. Sendmail is one I recall reading about: can
anyone supply names of, and recommendations about, others? I want the
simplest possible program for this one-user (Debian) machine.
Finally, can anyone enlighten me as to why a program like Mutt--which is
actually the only e-mail client I know of that won't interact with smtp
servers--will not do smtp? Is it for puristic reasons, i.e., because it
would somehow contaminate the program's perceived function by introducing
extra functionality? I.e., a line in the sand against feature-creep? Could
it be for some sort of security reasons?
Sorry for the long message. Input will be appreciated.
Thanks, James
PS Recommendations for other text-mode e-mail clients would also be
appreciated.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: smtp vs sendmail query
2006-08-10 19:07 ` smtp vs sendmail query James Miller
@ 2006-08-10 19:55 ` Ray Olszewski
0 siblings, 0 replies; 8+ messages in thread
From: Ray Olszewski @ 2006-08-10 19:55 UTC (permalink / raw)
To: linux-newbie
James Miller wrote:
> I think I'm finally ready to abandon Pine as my e-mail client and to
> start using Mutt. I thought of doing this a few years ago, but looking
> over Mutt documentation and config files left me bewildered. I'm sure I
> will still be confused about some of the program's workings, but it
> seems, after 4 years or so of using and admin'ing my Linux system(s), I
> have good enough grasp of the program's basics and related e-mail
> workings now that I'm ready to give it a serious go. This switch is also
> partly precipitated by certain ways in which Pine has been failing me.
> Despite what I've said above, the present message is not a Mutt-specific
> query: I'll probably be directing those to the Mutt user list. What I'm
> wondering about is something more fundamental about e-mail technology.
>
> One of the things that kept me from using Mutt previously was the fact
> that it does not do smtp, but rather apparently relies on other programs
> such as sendmail for passing mail to servers that in turn pass it to
> other servers and eventually to recipients. I don't care how stupid I
> might sound to the initiated in saying this, but for the
> technically-challenged such as myself, having an extra layer of program
> activity between the e-mail client and the outgoing server is confusing:
> it's just another set of configuration files to edit and keep current,
> and another place to look for errors should problems arise. At the same
> time, I suppose there are good reasons for having a separate program to
> do mail passing to outgoing servers. The most sensible reason I can
> think of is that e-mailing is often done in an institutional
> environment, one that has a machine on its network dedicated to mailing
> functions. I have no experience of working in such an environment, so
> I'm guessing at this, but that seems like it could provide a sensible
> explanation for the separation between e-mail client and outgoing mail
> server.
>
> Anyway, Pine does do smtp: you enter info about your smtp server in its
> config file, and away you go with sending out your mail. Mutt, as I
> understand it "will never do smtp" (quotation from a Mutt information
> site I haven't checked for a couple years but which I assume to reflect
> the current state of affairs). I will thus, I assume, need to look into
> getting and setting up a program to interact with the smtp server I will
> be sending mail through. Sendmail is one I recall reading about: can
> anyone supply names of, and recommendations about, others? I want the
> simplest possible program for this one-user (Debian) machine.
>
> Finally, can anyone enlighten me as to why a program like Mutt--which is
> actually the only e-mail client I know of that won't interact with smtp
> servers--will not do smtp? Is it for puristic reasons, i.e., because it
> would somehow contaminate the program's perceived function by
> introducing extra functionality? I.e., a line in the sand against
> feature-creep? Could it be for some sort of security reasons?
>
> Sorry for the long message. Input will be appreciated.
>
> Thanks, James
>
> PS Recommendations for other text-mode e-mail clients would also be
> appreciated.
James -- I don't know why (or even if, really) the authors of Mutt don't
build in smtp support. I could guess, but you don't need uninformed
guessing.
I'm replying only because you reminded us that you are a Debian user.
The off-the-shelf smtp program for Debian is exim, and if you did
anything resembling a standard install of any recent version of Debian,
you already have exim4 on your system, along with a symlink that lets
you run it as "sendmail":
new-flagg:/home/autovcr# ls -l /usr/sbin/sendmail
lrwxr-xr-x 1 root root 5 Aug 30 2005 /usr/sbin/sendmail -> exim4
The details on setting this up (this HowTo is for Debian-Sarge, but I
expect Etch and Sid are almost the same) are at
http://pkg-exim4.alioth.debian.org/README/README.Debian
The short version (for Sarge or Sid, probably Etch too): as root, run
"dpkg-reconfigure exim4-config" and tell it (I think, if I understand
your setup right) "mail sent by smarthost; no local mail". The
"smarthost" is the "smtp server" you identified to Pine.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 8+ messages in thread