Search results for query "change username Linux"
- 135 messages
Re: [CentOS] How to tell if I've been hacked?
by Rob Townley
On Sat, Aug 22, 2009 at 6:07 PM, Bill Campbell<centos(a)celestial.com> wrote:
> On Sat, Aug 22, 2009, Dave wrote:
>>On Sat, Aug 22, 2009 at 6:49 AM, Bill Campbell<centos(a)celestial.com> wrote:
>>> I review daily reports from over 50 systems every morning, checking changes
>>> found, usually taking no more than 10 minutes a day. The key is to keep
>>> the reports simple, and to make updating easy (and to have procedures that
>>> monitor systems to be sure they's still alive and reporting in).
>>
>>So how do you track the inevitable changes? Not saying you can't, just
>>curious. For me, when I look at a batch of changes, some of them are
>>obviously stuff I've done, other stuff not so obvious. I also filter
>>reports through a script that sort of does a diff and makes an attempt
>>to limit the boilerplate. Sometimes it is a bit too terse.
>
> First off, we don't allow automatic updates on most systems, much
> preferring to do them manually making it pretty easy to refresh
> the comparison database immediately after the update is complete.
> The odds that a cracker will get in and do their dirty deeds
> while this are going on are pretty low, and can probably be
> ignored.
>
> We handle pretty much all server stuff under the OpenPKG portable
> package management system so things like spamassassin, amavisd,
> clamav, and postfix are not the distribution versions, but those
> from OpenPKG (which are generally updated more quickly then the
> distribution's). A typical occurrence will be that we get an
> e-mail saying that clamav is out of date from the nightly
> freshclam update, I will pick up the new sources, update the
> OpenPKG SRPM for it, and deploy it 40 or so systems running it,
> and expect to see a corresponding set of notices the next morning
> that files under clamav have changed.
>
> The clusterssh program makes this sort of thing much more efficient
> as one can execute shell commands on multiple systems simultaneously.
>
>>> We create a file system initially, the same size as ``/'', and make a copy
>>> of ``/'' in it identical except for the /etc/fstab entry. This is not
>>> mounted in normal operations, but the system can be booted from it to get
>>> to a clean system.
>>
>>Wow, elaborate. How do you protect this file system from intruders?
>>Exterrnal and powerred off?
>
> That's one way to do it. We also run a fair number of Linux
> servers under VMware so periodic snapshots and backups simplify
> the task.
>
> I have not seen many successful cracks of Linux boxes that we
> have configured from scratch. Some basic things can be done to
> minimize the chances of cracks.
>
> + Create the baseline for intrusion detection tools before putting the
> syste on line, and monitor it daily.
>
> + Configure openssh to refuse password authentication requiring
> authorized_keys access.
>
> + Configure openssh with tcp_wrappers support, restricting access by IP
> address and/or domain names. I consider this absolutely mandatory if
> one needs to all username and password authentication.
>
> + Use fail2ban or similar techniques to quickly block IP addresses that
> are found probing the system (don't forget to look at POP and IMAP
> logs for failed login attempts).
>
> + Use /bin/false as the standard shell for accounts that don't have good
> reason for shell access. This does not affect e-mail or most services
> that a typical ISP customer needs.
>
> + Use OpenVPN for access. This works well even when in hotels with NAT
> firewalls, and is not easily hacked anonymously.
>
> + Restrict access of webmin and usermin to local networks so they are
> not vulnerable to outside attack. These services are available to
> people outside connecting with OpenVPN.
Cross Site Attacks (CSRF, XSS) make webmin very vulnerable in this
scenario. It is a bad idea to use a single browser. If in Firefox,
you already logged in to webmin and browse to a malicious site (many
reputable sites unknowingly have malicious javascript -- see
HoneyNet), the malicious site could do nasty things via webmin or any
other internal webserver. Yes, NoScript may help, but NoScript has to
be updated daily and Firefox restarted.
The best practice is to Install three separate browser application
such as Epiphany or Dillo and only use this for internal websites.
Use Firefox for email. Use Chrome for everything else. The idea is
to have completely separate processes using completely separate memory
and harddrive locations.
I don't think there are many malicious variants of InvisibleThings's
BluePill or BlueChicken, but if a malicious variant can elevate itself
to become the Hypervisor, then all of your virtual machines could be
monitored by a HyperKit -- rootkit in the hypervisor. Again, i don't
know if there are many malicious in-the-wild versions of bluepill, but
if just one malicious vmware image is uploaded to the Amazon EC2, then
every other VM on that same hardware at Amazon can be controlled by a
hyperkit. InvisibleThings are professional security researchers in
Poland, so the original bluepill isn't malicious. BlueChicken is to
evade detection by moving bluepill back and forth between the
hypervisor and a vm at will. Others are going to know more about what
actually is in-the-wild versus in the lab.
>
> + Restrict webmail, pop, and imap access to secure connections using
> https, tls, ssl. We have never been able to get the average ISP
> customer to use good passwords, but every little bit helps.
>
> Bill
> --
> INTERNET: bill(a)celestial.com Bill Campbell; Celestial Software LLC
> URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
> Voice: (206) 236-1676 Mercer Island, WA 98040-0820
> Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792
>
> bad economics will sink any economy no matter how much they believe this
> time things are different. They aren't. -- Arthur Laffer
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
16 years, 7 months
Re: [CentOS] using CentOS as an iSCSI server?
by Rudi Ahlers
> However, the OP is looking for a iscsi-target...which, if I am not
> wrong, does not quite exist yet in Centos/RHEL.
> _______________________________________________
you're right, I am looking to setup an iscsi target, but I couldn't
find a working tutorial, and this is very very new to me.
The one I found is this one:
http://www.cyberciti.biz/tips/howto-setup-linux-iscsi-target-sanwith-tgt.ht…
Yet, I can't get it to work.
[root@localhost ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.53
iscsiadm: cannot make connection to 192.168.0.53:3260 (111)
iscsiadm: connection to discovery address 192.168.0.53 failed
iscsiadm: cannot make connection to 192.168.0.53:3260 (111)
iscsiadm: connection to discovery address 192.168.0.53 failed
iscsiadm: caught SIGINT, exiting...
[root@localhost ~]# iscsiadm -m discovery -t sendtargets -p 127.0.0.1
iscsiadm: cannot make connection to 127.0.0.1:3260 (111)
iscsiadm: connection to discovery address 127.0.0.1 failed
iscsiadm: cannot make connection to 127.0.0.1:3260 (111)
iscsiadm: connection to discovery address 127.0.0.1 failed
iscsiadm: caught SIGINT, exiting...
Restarting /etc/init.d/iscsid doesn't give me any errors, and
/var/log/messages doesn't either:
[root@localhost ~]# tail -f /var/log/messages
Sep 8 17:41:34 localhost iscsid: iSCSI daemon with pid=13986 started!
Sep 8 17:44:40 localhost kernel: Removing netfilter NETLINK layer.
Sep 8 17:49:07 localhost iscsid: iscsid shutting down.
Sep 8 17:49:07 localhost kernel: Loading iSCSI transport class v2.0-724.
Sep 8 17:49:07 localhost kernel: iscsi: registered transport (tcp)
Sep 8 17:49:07 localhost kernel: iscsi: registered transport (iser)
Sep 8 17:49:07 localhost iscsid: iSCSI logger with pid=14373 started!
Sep 8 17:49:08 localhost iscsid: transport class version 2.0-724.
iscsid version 2.0-868
Sep 8 17:49:08 localhost iscsid: iSCSI daemon with pid=14374 started!
Sep 8 17:49:13 localhost iscsid: send fail Connection refused
Sep 8 17:54:47 localhost iscsid: iscsid shutting down.
Sep 8 17:54:47 localhost kernel: Loading iSCSI transport class v2.0-724.
Sep 8 17:54:47 localhost kernel: iscsi: registered transport (tcp)
Sep 8 17:54:47 localhost kernel: iscsi: registered transport (iser)
Sep 8 17:54:47 localhost iscsid: iSCSI logger with pid=14603 started!
Sep 8 17:54:48 localhost iscsid: transport class version 2.0-724.
iscsid version 2.0-868
Sep 8 17:54:48 localhost iscsid: iSCSI daemon with pid=14604 started!
The only changes I've made is this:
# To enable CHAP authentication set node.session.auth.authmethod
# to CHAP. The default is None.
node.session.auth.authmethod = CHAP
# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
node.session.auth.username = nas1
node.session.auth.password = password
discovery.sendtargets.auth.username = nas1
discovery.sendtargets.auth.password = password
the only errors I get is with iscsi itself:
[root@localhost ~]# /etc/init.d/iscsi start
iscsid (pid 15037 15036) is running...
Setting up iSCSI targets: iscsiadm: No records found!
[ OK ]
[root@localhost ~]#
--
Kind Regards
Rudi Ahlers
CEO, SoftDux Hosting
Web: http://www.SoftDux.com
Office: 087 805 9573
Cell: 082 554 7532
16 years, 6 months
[CentOS] odd entry in /var/log/messages
by Fred Smith
As of five or so days ago I'm getting a ton of messages like those below
in /var/log/messages:
Nov 29 13:17:59 fcshome sendmail[24977]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:17:59 fcshome sendmail[24977]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:28:21 fcshome sendmail[25101]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:28:21 fcshome sendmail[25101]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:38:06 fcshome sendmail[25209]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:38:06 fcshome sendmail[25209]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:41:26 fcshome sendmail[25275]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:41:26 fcshome sendmail[25275]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:50:41 fcshome sendmail[25504]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 13:50:41 fcshome sendmail[25504]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:05:52 fcshome sendmail[25797]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:05:52 fcshome sendmail[25797]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:15:42 fcshome sendmail[25905]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:15:42 fcshome sendmail[25905]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:25:36 fcshome sendmail[26021]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:25:36 fcshome sendmail[26021]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:36:29 fcshome sendmail[26171]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Nov 29 14:36:29 fcshome sendmail[26171]: unable to open Berkeley db /etc/sasldb2: No such file or directory
there are A TON of them.
I've not (intentionally) configured sasl for sendmail. I do have dovecot
configured so my wife can use pop3, and the authentication is specifically
set to use the local linux box's username and password. It has been set
that way for at least two years, and I've not changed anything.
I did some googling and most of the hits talk about configuration errors
in cyrus-sasl. But since I"m not running that, I don't know where else
to dig.
Anyone have a clue why I'm getting these, suddenly? and more importatnly,
how to fix it?
thanks!
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
"For the word of God is living and active. Sharper than any double-edged
sword, it penetrates even to dividing soul and spirit, joints and marrow;
it judges the thoughts and attitudes of the heart."
---------------------------- Hebrews 4:12 (niv) ------------------------------
10 years, 4 months
Re: [CentOS] Network FS w/o user setup
by Les Mikesell
Ted Miller wrote:
>
>> Is samba running there? If so, you are mostly done.
>
> Yes, at the moment I have Samba running, but apparently not properly
> configured. I am also in the process of moving this machine from Centos
> 4 to Centos 5, and am trying to do it better this time. At the moment
> office2 is dual boot, still defaulting to C4.
I don't think there should be a big difference samba-wise.
>> If you aren't already using samba, you need to 'smbpasswd
>> -a username' for each user and input the password (or go around and
>> let them type it themselves).
>
> Done at this point.
>
>> After this, a windows user mapping a samba-shared directory from your
>> office2 machine will have the same access as the same user logged in
>> locally. There are the same issues with directories that users share
>> with group permissions, but samba offers some extra options to force
>> owner/group/permissions on newly created files that will help.
>
> That is something I need to fix, because I do have some issues with
> group accessed files, where certain operations require me to log in as
> root and run a script that cleans up the file ownership, otherwise some
> users can no longer access the files. Any pointers on where to find
> documentation on this?
Newly created files default to having the group ownership of the primary
group of the user creating it, and the RH scheme is to give every user
his own group. You can do something like this in the samba share
configuration:
valid users = @groupname
force group = groupname
force create mode = 0775
force directory mode = 0775
This will make new files have the right group and r/w (and executable,
which you might not want). If files are also created on the Linux side
you need to 'chmod g+s' on the directory to make new files take the
group of the directory.
You can find samba docs here:
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/
> I have been using 'share' mode, but a little reading makes it sound like
> I should switch to 'user' mode to make my life easier. I have been
> adding various user permission lines to each share. Will they keep
> working if I just comment out those lines?
Share vs. user doesn't make a difference in how things work after the
connection is established - it controls when authentication happens.
Share mode just lets you browse the share list before authenticating and
you can connect to different shares with different credentials.
>> You might look at webmin, since it has an option to maintain unix and
>> samba passwords at the same time and it can also keep multiple
>> machines in sync.
>
> Does anyone maintain webmin for Centos? I have most of the common repos
> hooked to yum, but webmin draws a blank.
This is one of the reasons I usually install k12ltsp instead of the
stock centos distribution (you don't lose anything, it just adds some
extras and makes the updates yummable). You probably can grab the RPM
directly from the webmin site.
>> The other complication is that if you also want to share files via
>> NFS, the permissioning mechanism is entirely different. NFS just
>> looks at the uid/gid/modes like a local file, so you need to make the
>> password files consistent across all the Linux boxes.
>
> Does NFS work with windows? I have wasted considerable time on Google
> trying to answer that question, and the only answer I find is that there
> are commercial products that (for a per-seat fee) will connect windows
> to NFS.
On windows you would use 'services for unix'. But I'd stick to samba.
> I read that NFS v.4 was supposed to "play better" with windows,
> but I could not find any official comment, or windows drivers, or even
> any recommendations of client only drivers.
Don't know about that.
>> There is also the issue that users who have root access to their own
>> workstation can pretend to be any user over NFS.
>
> Not an issue in this situation, users do not have root access.
Do they have the same uid/gid, and group lists on their workstations as
on the file server?
>> For a single-user Linux workstation scenario, it might make more sense
>> to only provide samba shares and use cifs mounts instead of NFS. NFS
>> makes more sense between multiuser unix/linux boxes where only the
>> administrator(s) have root access.
>
> That is what I did under C4, but with considerable frustration, but
> maybe a simplified version of what I had (minus per-share permission
> listing in smb.conf) would get me most of what I want.
If it is one user per workstation, treating it just like the windows
connections with samba should work.
>> I don't think you need to code anything since there are already
>> several options with varying degrees of complexity. Centralizing
>> authentication will help if you have many users and password changes.
>> But that can be as simple as turning on domain controller emulation on
>> samba on your office2 server and configuring everything else (windows
>> and Linux) to use it.
>
> Any pointers to where I could learn the implications/pluses/minuses of
> that? It might be useful with my multiple machines (real and virtual)
> per user.
Samba authentication for linux just checks that a login/password match.
You still have to create the users and if you use NFS, make sure the
uid/gid's are all the same. For windows it works like a domain
controller and once you've logged in as a windows user, you
automatically authenticate to the samba shares as the same user and the
server can force login scripts to run on the client.
>> If these remote users are doing anything but video editing, another
>> useful option might be to use remote X logins or freenx/NX for a
>> remote Linux desktop directly from your office2 machine instead of
>> accessing its files on their workstation. How well it works depends
>> on what they are doing and the relative CPU and video use compared to
>> file access.
>
> Video editing is getting done on a windows-native-boot laptop. Video
> editing seems to be something that open source doesn't do very well.
I use a mac for the little I do, but I thought that
http://cvs.cinelerra.org/docs.php and http://lives.sourceforge.net were
supposed to be getting better.
--
Les Mikesell
lesmikesell(a)gmail.com
17 years, 9 months
Re: [CentOS] Dell Dimension 2400 W/Intel 845-G Video
by Denniston, Todd A CIV NAVSURFWARCENDIV Crane
Here is some hope for you.
I too have been fighting with an intel 845G, but mine is in an IBM built machine.
I just loaded the elrepo kernel-ml on a CentOS 6.6 system with an intel 845-G and now the X comes up correctly, i.e., at boot gdm is available visually for login. YYEEESS!!!
With either kernel, if you want any GL performance, you do _not_ want to use nomodeset, i.e., with nomodeset tux racer renders ~1FPS @800x600. Vesa is in the same boat and eats your main cpu to render anything.
With the standard _2.6_ kernels with CentOS 6.[56], even though the screen was blank (but with a mouse pointer) you could log in by simply typing the first letter of your username, press enter, enter your password, press enter, then wait for login, and because characters were messed up logout, at which point the restarted gdm and X would be working fine and you could login for a nice session.
Found this trick somewhere in the archives of this list IIRC.
Note:` telinit 3; telinit 5` OR `killall gdm-binary` do *NOT* help.
I don't have an xorg.conf or anything in xorg.conf.d, and I don't have any changes to the kernel line since install, i.e., using CentOS defaults.
With the elrepo kernel-ml, it does seem like there is a little more load on the system, but login has become normal and I see ~14FPS in tux racer @800x600 (OK it is not a speed daemon, but at least it is smoothed). After login the screen res defaults to 1920x1080 IIRC.
After login I have been using xrandr to change the screen res I want for each task (many web sites don't look right at anything above 1024x768).
xrandr -q #to see available sizes
and
xrandr -s 1024x768
good luck, and if this works for you and/or you find a better way, please let us know.
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the terms of any contract.
> -----Original Message-----
> From: Mark LaPierre [mailto:marklapier@gmail.com]
> Sent: Sunday, November 02, 2014 9:35 PM
> To: Mark LaPierre; Mail List CentOS Users
> Subject: Re: [CentOS] Dell Dimension 2400 W/Intel 845-G Video
>
> On 10/05/14 22:47, Mark LaPierre wrote:
> > Hey Y'all,
> >
> > I've been Googeling and experimenting for two days trying to find a way
> > to deal with the Intel 845-G video chipset in this Dell Dimension 2400.
<SNIP>
> >
> > There's a lot a cruft on the internet about problems with the Intel
> > 845-G chipset but no solutions that work for me. Does anyone know
> > how to get an successful installation on this hardware?
> >
>
> First I want to thank all of you who have offered up proposed solutions.
>
> I got the netinstall to work. Then used yum update to bring it up to
> the latest and greatest. I worked with 6.5 but got nowhere there. Then
> the 6.6 point release was ready so I did the yum update dance in hopes
> that 6.6 would be more cooperative.
>
> Today I've been googling, experimenting, and pretty much failing
> miserably. The best I've managed to get is to set the boot command to
> nomodeset, and the xorg.conf "Device" driver to vesa. I got 640x480
> resolution with the image offset to the left and down. Pretty much
> unusable. No improvement from my previous best effort documented above.
>
> I am able to open System/Preferences/Display where I could select a
> different resolution if I could see and reach the [Apply] button. That
> really doesn't matter since the only resolution available on the pull
> down is 640x480.
>
> I can't get the intel driver to yield a screen at all.
>
> I experimented with many VGA=NNN modes in combination with the vesa
> driver. No joy there. Not even the GDM screen comes up. The best I've
> been able to get from the intel driver is a mouse pointer in the middle
> of an otherwise black screen.
>
> When the graphics come up I can check the Xorg.0.log where I can see
> that the vesa driver says that resolutions including 1280x1024, 104x768,
> and 800x600 are viable options. I can't get it to use any of them.
>
> What think yee? Is there any hope of getting any resolution greater
> than 640x480 out of this thing?
>
> --
> _
> °v°
> /(_)\
> ^ ^ Mark LaPierre
> Registered Linux user No #267004
> https://linuxcounter.net/
> ****
11 years, 4 months
Re: [CentOS-es] Ayuda con SAMBA
by Mario Villela Larraza
No, solo es un servbidor de archivos, gracias intentare sus sujerecias
y les aviso los resultados.
2009/11/6 Mario Ganga <mario.ganga(a)gmail.com>:
> Hola
>
> Es un PDC o solo es servidor de archivos?? si es solo servidor de archivos
> el parametro debiera ser security user = share.
>
> para agregar usuarios, yo lo hago de esta manera:
>
> useradd -s /sbin/nologin usuario
>
> despues
>
> smbpasswd -a usuario
>
>
> Revisa esta pagina:
>
> http://joel-barrios.blogspot.com/2008/06/manual-de-samba-renovado-y-nuevos.…
>
>
> Espero te sea de ayuda.
>
>
> Atte.
> Mario Gnaga Castro.
>
>
>
> On Thu, Nov 5, 2009 at 7:29 PM, Mario Villela Larraza
> <mario.villelalarraza(a)gmail.com> wrote:
>>
>> hola amiguos tengo de nuevo problemas con mi servidor samba, ya esta
>> instalando y funcionando pero ahora mi problema es que no puedo
>> agregar un usuario con permisos tengo entrada a mis archivos pero como
>> invitado no puedo acceder con un usuario agregado ya con "smbuser"
>> tengo idea que el problema esta en el archivo de configuracion, lo
>> muestro aqui aver si aguien me puede ayudar con mi problema.
>>
>> muchas gracias de antemano
>>
>> #
>> # Sample configuration file for the Samba suite for Debian GNU/Linux.
>> #
>> #
>> # This is the main Samba configuration file. You should read the
>> # smb.conf(5) manual page in order to understand the options listed
>> # here. Samba has a huge number of configurable options most of which
>> # are not shown in this example
>> #
>> # Some options that are often worth tuning have been included as
>> # commented-out examples in this file.
>> # - When such options are commented with ";", the proposed setting
>> # differs from the default Samba behaviour
>> # - When commented with "#", the proposed setting is the default
>> # behaviour of Samba but the option is considered important
>> # enough to be mentioned here
>> #
>> # NOTE: Whenever you modify this file you should run the command
>> # "testparm" to check that you have not made any basic syntactic
>> # errors.
>> # A well-established practice is to name the original file
>> # "smb.conf.master" and create the "real" config file with
>> # testparm -s smb.conf.master >smb.conf
>> # This minimizes the size of the really used smb.conf file
>> # which, according to the Samba Team, impacts performance
>> # However, use this with caution if your smb.conf file contains nested
>> # "include" statements. See Debian bug #483187 for a case
>> # where using a master file is not a good idea.
>> #
>>
>> #======================= Global Settings =======================
>>
>> [global]
>>
>> ## Browsing/Identification ###
>>
>> # Change this to the workgroup/NT-domain name your Samba server will part
>> of
>> workgroup = ARQUIS
>>
>> # server string is the equivalent of the NT Description field
>> server string = Servidor De Archivos
>>
>> # Windows Internet Name Serving Support Section:
>> # WINS Support - Tells the NMBD component of Samba to enable its WINS
>> Server
>> # wins support = no
>>
>> # WINS Server - Tells the NMBD components of Samba to be a WINS Client
>> # Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
>> ; wins server = w.x.y.z
>>
>> # This will prevent nmbd to search for NetBIOS names through DNS.
>> dns proxy = no
>>
>> # What naming service and in what order should we use to resolve host
>> names
>> # to IP addresses
>> ; name resolve order = lmhosts host wins bcast
>>
>> #### Networking ####
>>
>> # The specific set of interfaces / networks to bind to
>> # This can be either the interface name or an IP address/netmask;
>> # interface names are normally preferred
>> ; interfaces = 127.0.0.0/8 eth0
>>
>> # Only bind to the named interfaces and/or networks; you must use the
>> # 'interfaces' option above to use this.
>> # It is recommended that you enable this feature if your Samba machine is
>> # not protected by a firewall or is a firewall itself. However, this
>> # option cannot handle dynamic or non-broadcast interfaces correctly.
>> ; bind interfaces only = yes
>>
>>
>>
>> #### Debugging/Accounting ####
>>
>> # This tells Samba to use a separate log file for each machine
>> # that connects
>> log file = /var/log/samba/log.%m
>>
>> # Cap the size of the individual log files (in KiB).
>> max log size = 1000
>>
>> # If you want Samba to only log through syslog then set the following
>> # parameter to 'yes'.
>> # syslog only = no
>>
>> # We want Samba to log a minimum amount of information to syslog.
>> Everything
>> # should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
>> # through syslog you should set the following parameter to something
>> higher.
>> syslog = 0
>>
>> # Do something sensible when Samba crashes: mail the admin a backtrace
>> panic action = /usr/share/samba/panic-action %d
>>
>>
>> ####### Authentication #######
>>
>> # "security = user" is always a good idea. This will require a Unix
>> account
>> # in this server for every user accessing the server. See
>> # /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
>> # in the samba-doc package for details.
>> security = user
>> username map = /etc/samba/smbusers
>>
>> # You may wish to use password encryption. See the section on
>> # 'encrypt passwords' in the smb.conf(5) manpage before enabling.
>> encrypt passwords = true
>>
>> # If you are using encrypted passwords, Samba will need to know what
>> # password database type you are using.
>> passdb backend = tdbsam
>>
>> obey pam restrictions = yes
>>
>> # This boolean parameter controls whether Samba attempts to sync the Unix
>> # password with the SMB password when the encrypted SMB password in the
>> # passdb is changed.
>> unix password sync = yes
>>
>> # For Unix password sync to work on a Debian GNU/Linux system, the
>> following
>> # parameters must be set (thanks to Ian Kahan
>> <<kahan(a)informatik.tu-muenchen.de> for
>> # sending the correct chat script for the passwd program in Debian Sarge).
>> passwd program = /usr/bin/passwd %u
>> passwd chat = *Enter\snew\s*\spassword:* %n\n
>> *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>>
>> # This boolean controls whether PAM will be used for password changes
>> # when requested by an SMB client instead of the program listed in
>> # 'passwd program'. The default is 'no'.
>> pam password change = yes
>>
>> # This option controls how unsuccessful authentication attempts are mapped
>> # to anonymous connections
>> map to guest = bad user
>>
>> ########## Domains ###########
>>
>> # Is this machine able to authenticate users. Both PDC and BDC
>> # must have this setting enabled. If you are the BDC you must
>> # change the 'domain master' setting to no
>> #
>> ; domain logons = yes
>> #
>> # The following setting only takes effect if 'domain logons' is set
>> # It specifies the location of the user's profile directory
>> # from the client point of view)
>> # The following required a [profiles] share to be setup on the
>> # samba server (see below)
>> ; logon path = \\%N\profiles\%U
>> # Another common choice is storing the profile in the user's home
>> directory
>> # (this is Samba's default)
>> # logon path = \\%N\%U\profile
>>
>> # The following setting only takes effect if 'domain logons' is set
>> # It specifies the location of a user's home directory (from the client
>> # point of view)
>> ; logon drive = H:
>> # logon home = \\%N\%U
>>
>> # The following setting only takes effect if 'domain logons' is set
>> # It specifies the script to run during logon. The script must be stored
>> # in the [netlogon] share
>> # NOTE: Must be store in 'DOS' file format convention
>> ; logon script = logon.cmd
>>
>> # This allows Unix users to be created on the domain controller via the
>> SAMR
>> # RPC pipe. The example command creates a user account with a disabled
>> Unix
>> # password; please adapt to your needs
>> ; add user script = /usr/sbin/adduser --quiet --disabled-password --gecos
>> "" %u
>>
>> # This allows machine accounts to be created on the domain controller via
>> the
>> # SAMR RPC pipe.
>> # The following assumes a "machines" group exists on the system
>> ; add machine script = /usr/sbin/useradd -g machines -c "%u machine
>> account" -d /var/lib/samba -s /bin/false %u
>>
>> # This allows Unix groups to be created on the domain controller via the
>> SAMR
>> # RPC pipe.
>> ; add group script = /usr/sbin/addgroup --force-badname %g
>>
>> ########## Printing ##########
>>
>> # If you want to automatically load your printer list rather
>> # than setting them up individually then you'll need this
>> # load printers = yes
>>
>> # lpr(ng) printing. You may wish to override the location of the
>> # printcap file
>> ; printing = bsd
>> ; printcap name = /etc/printcap
>>
>> # CUPS printing. See also the cupsaddsmb(8) manpage in the
>> # cupsys-client package.
>> ; printing = cups
>> ; printcap name = cups
>>
>> ############ Misc ############
>>
>> # Using the following line enables you to customise your configuration
>> # on a per machine basis. The %m gets replaced with the netbios name
>> # of the machine that is connecting
>> ; include = /home/samba/etc/smb.conf.%m
>>
>> # Most people will find that this option gives better performance.
>> # See smb.conf(5) and
>> /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
>> # for details
>> # You may want to add the following on a Linux system:
>> # SO_RCVBUF=8192 SO_SNDBUF=8192
>> # socket options = TCP_NODELAY
>>
>> # The following parameter is useful only if you have the linpopup package
>> # installed. The samba maintainer and the linpopup maintainer are
>> # working to ease installation and configuration of linpopup and samba.
>> ; message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &
>>
>> # Domain Master specifies Samba to be the Domain Master Browser. If this
>> # machine will be configured as a BDC (a secondary logon server), you
>> # must set this to 'no'; otherwise, the default behavior is recommended.
>> # domain master = auto
>>
>> # Some defaults for winbind (make sure you're not using the ranges
>> # for something else.)
>> ; idmap uid = 10000-20000
>> ; idmap gid = 10000-20000
>> ; template shell = /bin/bash
>>
>> # The following was the default behaviour in sarge,
>> # but samba upstream reverted the default because it might induce
>> # performance issues in large organizations.
>> # See Debian bug #368251 for some of the consequences of *not*
>> # having this setting and smb.conf(5) for details.
>> ; winbind enum groups = yes
>> ; winbind enum users = yes
>>
>> # Setup usershare options to enable non-root users to share folders
>> # with the net usershare command.
>>
>> # Maximum number of usershare. 0 (default) means that usershare is
>> disabled.
>> ; usershare max shares = 100
>>
>> # Allow users who've been granted usershare privileges to create
>> # public shares, not just authenticated ones
>> usershare allow guests = yes
>>
>> #======================= Share Definitions =======================
>>
>> # Un-comment the following (and tweak the other settings below to suit)
>> # to enable the default home directory shares. This will share each
>> # user's home directory as \\server\username
>>
>> [homes]
>> comment = /home/mario/infra;
>> browseable = no
>> valid users = %S
>> writable = yes
>>
>> # By default, the home directories are exported read-only. Change the
>> # next parameter to 'no' if you want to be able to write to them.
>> ; read only = yes
>>
>> # File creation mask is set to 0700 for security reasons. If you want to
>> # create files with group=rw permissions, set next parameter to 0775.
>> ; create mask = 0700
>>
>> # Directory creation mask is set to 0700 for security reasons. If you want
>> to
>> # create dirs. with group=rw permissions, set next parameter to 0775.
>> ; directory mask = 0700
>>
>> # By default, \\server\username shares can be connected to by anyone
>> # with access to the samba server. Un-comment the following parameter
>> # to make sure that only "username" can connect to \\server\username
>> # This might need tweaking when using external authentication schemes
>> ; valid users = %S
>>
>> # Un-comment the following and create the netlogon directory for Domain
>> Logons
>> # (you need to configure Samba to act as a domain controller too.)
>> ;[netlogon]
>> ; comment = Network Logon Service
>> ; path = /home/samba/netlogon
>> ; guest ok = yes
>> ; read only = yes
>> ; share modes = no
>>
>> # Un-comment the following and create the profiles directory to store
>> # users profiles (see the "logon path" option above)
>> # (you need to configure Samba to act as a domain controller too.)
>> # The path below should be writable by all users so that their
>> # profile directory may be created the first time they log on
>> ;[profiles]
>> ; comment = Users profiles
>> ; path = /home/samba/profiles
>> ; guest ok = no
>> ; browseable = no
>> ; create mask = 0600
>> ; directory mask = 0700
>>
>> [printers]
>> comment = All Printers
>> browseable = no
>> path = /var/spool/samba
>> printable = yes
>> guest ok = no
>> read only = yes
>> create mask = 0700
>>
>> # Windows clients look for this share name as a source of downloadable
>> # printer drivers
>> [print$]
>> comment = Printer Drivers
>> path = /var/lib/samba/printers
>> browseable = yes
>> read only = yes
>> guest ok = no
>> # Uncomment to allow remote administration of Windows print drivers.
>> # You may need to replace 'lpadmin' with the name of the group your
>> # admin users are members of.
>> # Please note that you also need to set appropriate Unix permissions
>> # to the drivers directory for these users to have write rights in it
>> ; write list = root, @lpadmin
>>
>> # A sample share for sharing your CD-ROM with others.
>> ;[cdrom]
>> ; comment = Samba server's CD-ROM
>> ; read only = yes
>> ; locking = no
>> ; path = /cdrom
>> ; guest ok = yes
>>
>> # The next two parameters show how to auto-mount a CD-ROM when the
>> # cdrom share is accesed. For this to work /etc/fstab must contain
>> # an entry like this:
>> #
>> # /dev/scd0 /cdrom iso9660 defaults,noauto,ro,user 0 0
>> #
>> # The CD-ROM gets unmounted automatically after the connection to the
>> #
>> # If you don't want to use auto-mounting/unmounting make sure the CD
>> # is mounted on /cdrom
>> #
>> ; preexec = /bin/mount /cdrom
>> ; postexec = /bin/umount /cdrom
>>
>>
>> [Infra] comment = Directorio del servidor Infraestructura
>>
>> path = /home/mario/infra
>>
>> guest ok = no
>>
>> read only = Yes
>>
>> write list = administrador
>>
>> directory mask = 0755
>>
>> create mask = 0644
>>
>>
>>
>> aparte cree un archivo donde registro los usuarios que pueden acceder
>> que se llama smbusers y este solo tiene el sigueiente texto
>>
>> usuario_linux = "usuario_windows"
>> _______________________________________________
>> CentOS-es mailing list
>> CentOS-es(a)centos.org
>> http://lists.centos.org/mailman/listinfo/centos-es
>
>
>
>
> _______________________________________________
> CentOS-es mailing list
> CentOS-es(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos-es
>
>
16 years, 4 months
Re: [CentOS] scp via another server
by H
On 06/12/2016 08:28 PM, J Martin Rushton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/06/16 18:07, H wrote:
>> On 06/12/2016 05:21 PM, J Martin Rushton wrote: $ scp
>> svr2:/path/to/source svr1:/path/to/dest
>>
>> You'll get twice the network traffic since the copy is running on
>> your workstation (or whatever).
>>
>> On 12/06/16 15:40, H wrote:
>>>>> I normally use ssh to log into a remote server, change
>>>>> directory and then use scp from there to copy files from
>>>>> another remote server to the first one.
>>>>>
>>>>> Now the first server has been hit by continuous error
>>>>> correction messages from the ECC controller, all of which are
>>>>> corrected, and I am unable to get a command line to issue the
>>>>> required commands to change directory and then run scp from
>>>>> the other server. I have no problems, however, getting into
>>>>> the first server - except for being drowned by the error
>>>>> correction messages and the server seems to be running
>>>>> "fine".
>>>>>
>>>>> Until I am able to get to the server and investigate, is it
>>>>> possible to accomplish the above on a single command line,
>>>>> thus avoiding seeing the error messages? I should add that
>>>>> both the first and second server are set up to accept keys
>>>>> and not passwords so at least I don't have to worry about
>>>>> that.
>>>>>
>>>>> Thank you. _______________________________________________
>>>>> CentOS mailing list CentOS(a)centos.org
>>>>> https://lists.centos.org/mailman/listinfo/centos
>>> _______________________________________________ CentOS mailing
>>> list CentOS(a)centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>> This did not work even though the same user is authenticated on
>> both servers and I have no problems ssh'ing into either of the two
>> servers. The message is "permission denied."
>>
>> Presumably some problem with being recognized on both systems?
>> _______________________________________________ CentOS mailing
>> list CentOS(a)centos.org
>> https://lists.centos.org/mailman/listinfo/centos
> It sounds like it. Try:
> $ ssh svr1 pwd
> $ ssh svr2 pwd
> If they work without asking for a password then there is a deeper
> configuration issue. If you do get prompted for a password then you
> need to sort out your access. If the username differs try
> <user>@<host> both for the ssh test and the scp command.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJXXaneAAoJEAF3yXsqtyBl80YP/RqDYrhpcR42FtWnfHPwACoU
> /ogF7LMhSVEpIBwZlmSY7cSUm9uqQgHWPt/ufI3S9kLXzVpZejx1FolNNvkASTRV
> mtCp9g31CGDxfEzuf19ip8dVJkRDJdFpFYkjgFUHXDfm20ub7Louf89d/0Zi/7fq
> FUMC/RVUCu0CALlyXrr1YtuIVS9kR/8Jb459uA9L9lHXAkPXzHO0zOxu8F/WuNae
> uMC9DoVEMlJ9Pf4o2PV7PvHjiXTXaASAspUfBJ3uWHARhxopc6vaPhglux2QIwIf
> 4e/8DgH2Cnzwd1Dkv+OOEcNzVx2M/02zg9DcBXogU19dE1NPNtj/pDk5oRgRpNaF
> XEiS+vUV55+5XfukodkbI5LZ9RKUunWJXK+4EZWi0wEET5yVNzLoCBfX5o4Na1G4
> fPJUJAAsX0MnBy/nzw0bmkItPixD7uOWOb79BS+q3HDcZUyUYokXI6OBFtF8doAw
> eL2+tvefC1dJWxoZez98XvvFaOQXfMCIv38A5EuOFwnkMCKFnQ4nGbJtFv+Mbzhw
> 9YB5qeHIFfpCJUA6s0ilS/cJvPMmH60BNCoej8PrEV02hxoqUgtcwbmM+r/JsX0X
> 7/Lz7IASBKbs0aGSh5HHiwfkGT40KeOY33VNULBALuHFfQxTWSymWYcXlUWY9mjj
> WKvNDPk0e0nU0y9kZIMn
> =RpfJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos
I don't know. I have no problems with 'ssh user1@server1' and 'ssh user1@server2' or running 'scp user1@server2:somefilesserver2 tolocationonserver1' after having ssh'ed into server 1.
I just tried 'ssh user1@server1 'scp user1@server2:somefilesserver2 tolocationonserver1'' which worked fine suggesting that the configuration is correct.
There seems to be something broken when using scp between two remote locations. Some posts on the 'net suggest using 'scp -3' to do an intermediate copy to the workstation between the two remote servers but that option does not seem to have been implemented yet on scp for Centos 6.7.
9 years, 9 months
Re: [CentOS] Network FS w/o user setup
by Ted Miller
Thanks for the reply. I think we are making progress, see
comments/questions interspersed below.
Les Mikesell wrote:
> Ted Miller wrote:
>> Johnny Hughes wrote:
>>>
>>> Well ... you would need to Join the "Samba Server" to your "Windows
>>> Domain". If that domain is ADS (Active Directory Services) then it
>>> is a different procedure than if it is a WinNT type Windows Domain.
>>
>> This is getting well outside the range of complexity that I am looking
>> for. If I add more detail, maybe something more suitable to my
>> situation will suggest itself to members of the list.
>>
>> 1. This is a very small network, only one primary file server
>> (office2). A second file server (RAIDer1) has only one shared
>> directory, so is not really an issue.
>>
>> 2. Users log in primarily from Linux boxes, but have to run virtual
>> Windows machines for some software, and also log in from Windows laptops.
>
> Virtual windows machines should be no different in terms of network
> connections, so you can ignore that distinction.
>
>> 3. office2 is set up with logins and home directories for all users,
>> and directories are permissioned such that users can run programs on
>> office2 (if needed) and directory permissions work right.
>
> Is samba running there? If so, you are mostly done.
Yes, at the moment I have Samba running, but apparently not properly
configured. I am also in the process of moving this machine from Centos 4
to Centos 5, and am trying to do it better this time. At the moment
office2 is dual boot, still defaulting to C4.
>> Because all the users and permissions already exist on office2, I
>> would like those existing permissions to be reflected when the file
>> system is shared, just the same as when it is accessed locally. To
>> restate: my desire is that users, logins, and permissions be identical
>> whether a user is logged into office2 or whether that user is using a
>> network file share from another virtual or physical machine, running
>> Linux or Windows. I would think there would be a "market" for a
>> network file system where sharing a directory tree involved no more
>> than assigning a network share name to it. If (and only if) you had
>> access to the file locally, you now have access to it on the network.
>> Very simple to administer, very simple to understand--one set of
>> permissions (kept locally) works everywhere.
>
> This mostly "just works" if you deal with a few complications that on a
> small scale can be worked around without too much trouble. The first
> complication is that you need to maintain passwords separately for Linux
> and Windows because they are stored with different encryption. If you
> aren't already using samba, you need to 'smbpasswd -a username' for each
> user and input the password (or go around and let them type it
> themselves).
Done at this point.
> After this, a windows user mapping a samba-shared
> directory from your office2 machine will have the same access as the
> same user logged in locally. There are the same issues with directories
> that users share with group permissions, but samba offers some extra
> options to force owner/group/permissions on newly created files that
> will help.
That is something I need to fix, because I do have some issues with group
accessed files, where certain operations require me to log in as root and
run a script that cleans up the file ownership, otherwise some users can no
longer access the files. Any pointers on where to find documentation on this?
> Windows/samba connections are treated as single users with
> all access through that connection treated with the permissions of the
> matching linux login. With samba in 'user' mode, the authentication is
> done before you can even see the shares and even if you have multiple
> shares mapped from the server they must all be as the same user. There
> is also a 'share' mode where you authenticate separately per connection.
I have been using 'share' mode, but a little reading makes it sound like I
should switch to 'user' mode to make my life easier. I have been adding
various user permission lines to each share. Will they keep working if I
just comment out those lines?
>> From everything I have heard, a windows domain controller would be
>> more work than it is worth for this size of project, as I am looking
>> for something machine-scale, not enterprise scale.
>
> You might look at webmin, since it has an option to maintain unix and
> samba passwords at the same time and it can also keep multiple machines
> in sync.
Does anyone maintain webmin for Centos? I have most of the common repos
hooked to yum, but webmin draws a blank.
> The other complication is that if you also want to share files
> via NFS, the permissioning mechanism is entirely different. NFS just
> looks at the uid/gid/modes like a local file, so you need to make the
> password files consistent across all the Linux boxes.
Does NFS work with windows? I have wasted considerable time on Google
trying to answer that question, and the only answer I find is that there
are commercial products that (for a per-seat fee) will connect windows to
NFS. I read that NFS v.4 was supposed to "play better" with windows, but I
could not find any official comment, or windows drivers, or even any
recommendations of client only drivers.
> There is also the
> issue that users who have root access to their own workstation can
> pretend to be any user over NFS.
Not an issue in this situation, users do not have root access.
> For a single-user Linux workstation
> scenario, it might make more sense to only provide samba shares and use
> cifs mounts instead of NFS. NFS makes more sense between multiuser
> unix/linux boxes where only the administrator(s) have root access.
That is what I did under C4, but with considerable frustration, but maybe a
simplified version of what I had (minus per-share permission listing in
smb.conf) would get me most of what I want.
>> I hope this more clearly expresses my desires, even if only so that
>> everyone can tell me to keep dreaming, because what I want doesn't
>> exist--or in the open source tradition, quit dreaming and start
>> coding. (Unfortunately I am still working on my first C++ lesson book.)
>
> I don't think you need to code anything since there are already several
> options with varying degrees of complexity. Centralizing
> authentication will help if you have many users and password changes.
> But that can be as simple as turning on domain controller emulation on
> samba on your office2 server and configuring everything else (windows
> and Linux) to use it.
Any pointers to where I could learn the implications/pluses/minuses of
that? It might be useful with my multiple machines (real and virtual) per
user.
> Or it can be as complicated as running a separate
> Active Domain controller. I've always been surprised that Linux
> distributions didn't come with a pre-configured LDAP server that
> automatically worked for local users and samba and could server other
> Linux boxes as you add them without starting over, but so far I don't
> think any provide that.
Sounds like a great idea for a CentosPlus .rpm.
>> Sorry I neglected this (and all other) threads for a week or more, as
>> I had to learn how to do video editing to rescue an otherwise
>> disastrously unusable video project for my employer.
>
> If these remote users are doing anything but video editing, another
> useful option might be to use remote X logins or freenx/NX for a remote
> Linux desktop directly from your office2 machine instead of accessing
> its files on their workstation. How well it works depends on what they
> are doing and the relative CPU and video use compared to file access.
Video editing is getting done on a windows-native-boot laptop. Video
editing seems to be something that open source doesn't do very well.
Ted Miller
17 years, 9 months
Re: [CentOS] imap on Centos 4
by Tony Wicks
Ok, I've got this new dovecot working thanks. The last bit is the users
kept their imap folders on the /home/username/* directories, after
copint one over and trying it a mail clints (thunderbird) cannot see the
directories, have I missed something in the dovecot.conf file ?
>Actually, the more direct replacement would be Dovecot. Cyrus can be
>complicated to set up and get running.
>
>Matt
>
>
>
[root@pheonix tonyw]# vi /etc/dovecot.conf
## Dovecot 1.0 configuration file
# Default values are shown after each value, it's not required to uncomment
# any of the lines. Exception to this are paths, they're just examples
# with real defaults being based on configure options. The paths listed here
# are for configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
# --with-ssldir=/usr/share/ssl
# Base directory where to store runtime data.
#base_dir = /var/run/dovecot/
# Protocols we want to be serving:
# imap imaps pop3 pop3s
#protocols = imap imaps
protocols = imap pop3
# IP or host address where to listen in for connections. It's not currently
# possible to specify multiple addresses. "*" listens in all IPv4
interfaces.
# "[::]" listens in all IPv6 interfaces, but may also listen in all IPv4
# interfaces depending on the operating system. You can specify ports with
# "host:port".
imap_listen = [::]
pop3_listen = [::]
# IP or host address where to listen in for SSL connections. Defaults
# to above non-SSL equilevants if not specified.
#imaps_listen =
#pop3s_listen =
# Disable SSL/TLS support.
#ssl_disable = no
# PEM encoded X.509 SSL/TLS certificate and private key. They're opened
before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
#ssl_cert_file = /usr/share/ssl/certs/dovecot.pem
#ssl_key_file = /usr/share/ssl/private/dovecot.pem
# SSL parameter file. Master process generates this file for login
processes.
# It contains Diffie Hellman and RSA parameters.
#ssl_parameters_file = /var/run/dovecot/ssl-parameters.dat
# How often to regenerate the SSL parameters file. Generation is quite CPU
# intensive operation. The value is in hours, 0 disables regeneration
# entirely.
#ssl_parameters_regenerate = 24
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and
# IPv6 ::1 addresses are considered secure, this setting has no effect if
# you connect from those addresses.
disable_plaintext_auth = no
# Use this logfile instead of syslog(). /dev/stderr can be used if you
want to
# use stderr for logging (ONLY /dev/stderr - otherwise it is closed).
#log_path =
# For informational messages, use this logfile instead of the default
#info_log_path =
# Prefix for each line written to log file. % codes are in strftime(3)
# format.
#log_timestamp = "%b %d %H:%M:%S "
##
## Login processes
##
# Directory where authentication process places authentication UNIX sockets
# which login needs to be able to connect to. The sockets are created when
# running as root, so you don't have to worry about permissions. Note that
# everything in this directory is deleted when Dovecot is started.
login_dir = /var/run/dovecot-login
# chroot login process to the login_dir. Only reason not to do this is
if you
# wish to run the whole Dovecot without roots.
#login_chroot = yes
##
## IMAP login process
##
login = imap
# Executable location.
#login_executable = /usr/libexec/dovecot/imap-login
# User to use for the login process. Create a completely new user for this,
# and don't use it anywhere else. The user must also belong to a group where
# only it has access, it's used to control access for authentication
process.
#login_user = dovecot
# Set max. process size in megabytes. If you don't use
# login_process_per_connection you might need to grow this.
#login_process_size = 32
# Should each login be processed in it's own process (yes), or should one
# login process be allowed to process multiple connections (no)? Yes is more
# secure, espcially with SSL/TLS enabled. No is faster since there's no need
# to create processes all the time.
#login_process_per_connection = yes
# Number of login processes to create. If login_process_per_user is
# yes, this is the number of extra processes waiting for users to log in.
#login_processes_count = 3
# Maximum number of extra login processes to create. The extra process count
# usually stays at login_processes_count, but when multiple users start
logging
# in at the same time more extra processes are created. To prevent
fork-bombing
# we check only once in a second if new processes should be created - if all
# of them are used at the time, we double their amount until limit set
by this
# setting is reached. This setting is used only if login_process_per_use
is yes.
#login_max_processes_count = 128
# Maximum number of connections allowed in login state. When this limit is
# reached, the oldest connections are dropped. If login_process_per_user
# is no, this is a per-process value, so the absolute maximum number of
users
# logging in actually login_processes_count * max_logging_users.
#login_max_logging_users = 256
##
## POP3 login process
##
# Settings default to same as above, so you don't have to set anything
# unless you want to override them.
login = pop3
# Exception to above rule being the executable location.
#login_executable = /usr/libexec/dovecot/pop3-login
##
## Mail processes
##
# Maximum number of running mail processes. When this limit is reached,
# new users aren't allowed to log in.
#max_mail_processes = 1024
# Show more verbose process titles (in ps). Currently shows user name and
# IP address. Useful for seeing who are actually using the IMAP processes
# (eg. shared mailboxes or if same uid is used for multiple accounts).
#verbose_proctitle = no
# Show protocol level SSL errors.
#verbose_ssl = no
# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
#first_valid_uid = 500
#last_valid_uid = 0
# Valid GID range for users, defaults to non-root/wheel. Users having
# non-valid GID as primary group ID aren't allowed to log in. If user
# belongs to supplementary groups with non-valid GIDs, those groups are
# not set.
#first_valid_gid = 1
#last_valid_gid = 0
# Grant access to these extra groups for mail processes. Typical use
would be
# to give "mail" group write access to /var/mail to be able to create
dotlocks.
#mail_extra_groups =
# ':' separated list of directories under which chrooting is allowed for
mail
# processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too).
# This setting doesn't affect login_chroot or auth_chroot variables.
# WARNING: Never add directories here which local users can modify, that
# may lead to root exploit. Usually this should be done only if you don't
# allow shell access for users. See doc/configuration.txt for more
information.
#valid_chroot_dirs =
# Default chroot directory for mail processes. This can be overridden by
# giving /./ in user's home directory (eg. /home/./user chroots into /home).
#mail_chroot =
# Default MAIL environment to use when it's not set. By leaving this empty
# dovecot tries to do some automatic detection as described in
# doc/mail-storages.txt. There's a few special variables you can use:
#
# %u - username
# %n - user part in user@domain, same as %u if there's no domain
# %d - domain part in user@domain, empty if user there's no domain
# %h - home directory
#
# You can also limit a width of string by giving the number of max.
characters
# after the '%' character. For example %1u gives the first character of
# username. Some examples:
#
# default_mail_env = maildir:/var/mail/%1u/%u/Maildir
# default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u
# default_mail_env = mbox:/var/mail/%d/%n/:INDEX=/var/indexes/%d/%n
#
#default_mail_env =
# Space-separated list of fields to cache for all mails. Currently these
# fields are allowed followed by a list of commands they speed up:
#
# Envelope - FETCH ENVELOPE and SEARCH FROM, TO, CC, BCC, SUBJECT,
# SENTBEFORE, SENTON, SENTSINCE, HEADER MESSAGE-ID,
# HEADER IN-REPLY-TO
# Body - FETCH BODY
# Bodystructure - FETCH BODY, BODYSTRUCTURE
# MessagePart - FETCH BODY[1.2.3] (ie. body parts), RFC822.SIZE,
# SEARCH SMALLER, LARGER, also speeds up BODY/BODYSTRUCTURE
# generation. This is always set with mbox mailboxes, and
# also default with Maildir.
#
# Different IMAP clients work in different ways, that's why Dovecot by
default
# only caches MessagePart which speeds up most operations. Whenever client
# does something where caching could be used, the field is automatically
marked
# to be cached later. For example after FETCH BODY the BODY will be cached
# for all new messages. Normally you should leave this alone, unless you
know
# what most of your IMAP clients are. Caching more fields than needed makes
# the index files larger and generate useless I/O.
#
# With maildir there's one extra optimization - if nothing is cached,
indexing
# the maildir becomes much faster since it's not opening any of the mail
files.
# This could be useful if your IMAP clients access only new mails.
#mail_cache_fields = MessagePart
# SEARCH SMALLER, LARGER, also speeds up BODY/BODYSTRUCTURE
# generation. This is always set with mbox mailboxes, and
# also default with Maildir.
#
# Different IMAP clients work in different ways, that's why Dovecot by
default
# only caches MessagePart which speeds up most operations. Whenever client
# does something where caching could be used, the field is automatically
marked
# to be cached later. For example after FETCH BODY the BODY will be cached
# for all new messages. Normally you should leave this alone, unless you
know
# what most of your IMAP clients are. Caching more fields than needed makes
# the index files larger and generate useless I/O.
#
# With maildir there's one extra optimization - if nothing is cached,
indexing
# the maildir becomes much faster since it's not opening any of the mail
files.
# This could be useful if your IMAP clients access only new mails.
#mail_cache_fields = MessagePart
# Space-separated list of fields that Dovecot should never set to be cached.
# Useful if you want to save disk space at the cost of more I/O when the
fields
# needed.
#mail_never_cache_fields =
# Workarounds for various client bugs:
# oe6-fetch-no-newmail:
# Never send EXISTS/RECENT when replying to FETCH command. Outlook
Express
# seems to think they are FETCH replies and gives user "Message no
longer
# in server" error. Note that OE6 still breaks even with this workaround
# if synchronization is set to "Headers Only".
# outlook-idle:
# Outlook and Outlook Express never abort IDLE command, so if no mail
# arrives in half a hour, Dovecot closes the connection. This is still
# fine, except Outlook doesn't connect back so you don't see if new mail
# arrives.
# outlook-pop3-no-nuls:
# Outlook and Outlook Express hang if mails contain NUL characters.
# This setting replaces them with 0x80 character.
#client_workarounds =
# Dovecot can notify client of new mail in selected mailbox soon after it's
# received. This setting specifies the minimum interval in seconds between
# new mail notifications to client - internally they may be checked more or
# less often. Setting this to 0 disables the checking.
# NOTE: Evolution client breaks with this option when it's trying to APPEND.
#mailbox_check_interval = 0
# Like mailbox_check_interval, but used for IDLE command.
#mailbox_idle_check_interval = 30
# Allow full filesystem access to clients. There's no access checks
other than
# what the operating system does for the active UID/GID. It works with both
# maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/
# or ~user/.
#mail_full_filesystem_access = no
# Maximum allowed length for custom flag name. It's only forced when trying
# to create new flags.
#mail_max_flag_length = 50
# Save mails with CR+LF instead of plain LF. This makes sending those mails
# take less CPU, especially with sendfile() syscall with Linux and FreeBSD.
# But it also creates a bit more disk I/O which may just make it slower.
#mail_save_crlf = no
# Use mmap() instead of read() to read mail files. read() seems to be a bit
# faster with my Linux/x86 and it's better with NFS, so that's the default.
#mail_read_mmaped = no
# By default LIST command returns all entries in maildir beginning with dot.
# Enabling this option makes Dovecot return only entries which are
directories.
# This is done by stat()ing each entry, so it causes more disk I/O.
# (For systems setting struct dirent->d_type, this check is free and it's
# done always regardless of this setting)
#maildir_stat_dirs = no
# Copy mail to another folders using hard links. This is much faster than
# actually copying the file. This is problematic only if something modifies
# the mail in one folder but doesn't want it modified in the others. I don't
# know any MUA which would modify mail files directly. IMAP protocol also
# requires that the mails don't change, so it would be problematic in
any case.
# If you care about performance, enable it.
#maildir_copy_with_hardlinks = no
# Check if mails' content has been changed by external programs. This slows
# down things as extra stat() needs to be called for each file. If
changes are
# noticed, the message is treated as a new message, since IMAP protocol
# specifies that existing messages are immutable.
#maildir_check_content_changes = no
# Which locking methods to use for locking mbox. There's three available:
# dotlock: Create <mailbox>.lock file. This is the oldest and most NFS-safe
# solution. If you want to use /var/mail/ like directory, the
users
# will need write access to that directory.
# fcntl : Use this if possible. Works with NFS too if lockd is used.
# flock : May not exist in all systems. Doesn't work with NFS.
#
# You can use both fcntl and flock too; if you do the order they're declared
# with is important to avoid deadlocks if other MTAs/MUAs are using both
fcntl
# and flock. Some operating systems don't allow using both of them
# simultaneously, eg. BSDs. If dotlock is used, it's always created first.
mbox_locks = fcntl
# Should we create dotlock file even when we want only a read-lock? Setting
# this to yes hurts the performance when the mailbox is accessed
simultaneously
# by multiple processes, but it's needed for reliable reading if no other
# locking methods are available.
#mbox_read_dotlock = no
# Maximum time in seconds to wait for lock (all of them) before aborting.
#mbox_lock_timeout = 300
# If dotlock exists but the mailbox isn't modified in any way, override the
# lock file after this many seconds.
#mbox_dotlock_change_timeout = 30
# umask to use for mail files and directories
#umask = 0077
# Drop all privileges before exec()ing the mail process. This is mostly
# meant for debugging, otherwise you don't get core dumps. Note that setting
# this to yes means that log file is opened as the logged in user, which
# might not work. It could also be a small security risk if you use
single UID
# for multiple users, as the users could ptrace() each others processes
then.
#mail_drop_priv_before_exec = no
##
## IMAP process
##
# Executable location
#imap_executable = /usr/libexec/dovecot/imap
# Set max. process size in megabytes. Most of the memory goes to mmap()ing
# files, so it shouldn't harm much even if this limit is set pretty high.
#imap_process_size = 256
# Support for dynamically loadable modules.
#imap_use_modules = no
#imap_modules = /usr/lib/dovecot/imap
##
## POP3 process
##
# Executable location
#pop3_executable = /usr/libexec/dovecot/pop3
# Set max. process size in megabytes. Most of the memory goes to mmap()ing
# files, so it shouldn't harm much even if this limit is set pretty high.
#pop3_process_size = 256
# Support for dynamically loadable modules.
#pop3_use_modules = no
#pop3_modules = /usr/lib/dovecot/pop3
##
## Authentication processes
##
# An Authentication process is a child process used by Dovecot that
# handles the authentication steps. The steps cover an authentication
# mechanism (auth_mechanisms, how the client authenticates in the IMAP or
# POP3 protocol), which password database should be queried (auth_passdb),
# and which user database should be queried (auth_userdb, to obtain
# UID, GID, and location of the user's mailbox/home directory).
#
# You can have multiple processes, though a typical configuration will
# have only one. Each time "auth = xx" is seen, a new process
# definition is started. The point of multiple processes is to be able
# to set stricter permissions. (See auth_user below.)
#
# Just remember that only one Authentication process is asked for the
# password, so you can't have different passwords accessible through
# different process definitions (unless they have different
# auth_mechanisms, and you're ok with having different password for
# each mechanisms).
# Authentication process name.
auth = default
# Specifies how the client authenticates in the IMAP protocol.
# Space separated list of permitted authentication mechanisms:
# anonymous plain digest-md5 cram-md5
#
# anonymous - No authentication required.
# plain - The password is sent as plain text. All IMAP/POP3 clients
# support this, and the password can be encrypted by Dovecot to match
# any of the encryption schemes used in password databases.
# digest-md5 and cram-md5 - both encrypt the password so it is more
# secure in transit, but are not well supported by clients, and
# require that the password database use a matching encryption
# scheme (or be in plaintext).
#
# See auth.txt for more details.
#
# If you are using SSL there is less benefit to digest-md5 and
# cram-md5 as the communication is already encrypted.
auth_mechanisms = plain
# Space separated list of realms for SASL authentication mechanisms that
need
# them. You can leave it empty if you don't want to support multiple realms.
# Many clients simply use the first one listed here, so keep the default
realm
# first.
#auth_realms =
# Default realm/domain to use if none was specified. This is used for both
# SASL realms and appending @domain to username in plaintext logins.
#auth_default_realm =
# Where user database is kept:
# passwd: /etc/passwd or similiar, using getpwnam()
# passwd-file <path>: passwd-like file with specified location
# static uid=<uid> gid=<gid> home=<dir template>: static settings
# vpopmail: vpopmail library
# ldap <config path>: LDAP, see doc/dovecot-ldap.conf
# pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf
auth_userdb = passwd
# Where password database is kept:
# passwd: /etc/passwd or similiar, using getpwnam()
# shadow: /etc/shadow or similiar, using getspnam()
# pam [<service> | *]: PAM authentication
# passwd-file <path>: passwd-like file with specified location
# vpopmail: vpopmail authentication
# ldap <config path>: LDAP, see doc/dovecot-ldap.conf
# pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf
#auth_passdb = pgsql /usr/local/etc/dovecot-pgsql.conf
auth_passdb = pam
#auth_executable = /usr/libexec/dovecot/dovecot-auth
# Set max. process size in megabytes.
#auth_process_size = 256
# User to use for the process. This user needs access to only user and
# password databases, nothing else. Only shadow and pam authentication
# requires roots, so use something else if possible. Note that passwd
# authentication with BSDs internally accesses shadow files, which also
# requires roots.
auth_user = root
# Directory where to chroot the process. Most authentication backends don't
# work if this is set, and there's no point chrooting if auth_user is root.
#auth_chroot =
# Number of authentication processes to create
#auth_count = 1
# List of allowed characters in username. If the user-given username
contains
# a character not listed in here, the login automatically fails. This is
just
# an extra check to make sure user can't exploit any potential quote
escaping
# vulnerabilities with SQL/LDAP databases. If you want to allow all
characters,
# set this value to empty.
#auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
# Username to use for users logging in with ANONYMOUS SASL mechanism
#auth_anonymous_username = anonymous
# More verbose logging. Useful for figuring out why authentication isn't
# working.
#auth_verbose = no
# Even more verbose logging for debugging purposes. Shows for example SQL
# queries.
#auth_debug = no
# digest-md5 authentication process. It requires special MD5 passwords which
# /etc/shadow and PAM doesn't support, so we never need roots to handle it.
# Note that the passwd-file is opened before chrooting and dropping root
# privileges, so it may be 0600-root owned file.
#auth = digest_md5
#auth_mechanisms = digest-md5
#auth_realms =
#auth_userdb = passwd-file /etc/passwd.imap
#auth_passdb = passwd-file /etc/passwd.imap
#auth_user = imapauth
#auth_chroot =
# if you plan to use only passwd-file, you don't need the two auth
processes,
# simply set "auth_methods = plain digest-md5"
[root@pheonix tonyw]# more /etc/dovecot.conf
## Dovecot 1.0 configuration file
# Default values are shown after each value, it's not required to uncomment
# any of the lines. Exception to this are paths, they're just examples
# with real defaults being based on configure options. The paths listed here
# are for configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
# --with-ssldir=/usr/share/ssl
# Base directory where to store runtime data.
#base_dir = /var/run/dovecot/
# Protocols we want to be serving:
# imap imaps pop3 pop3s
#protocols = imap imaps
protocols = imap pop3
# IP or host address where to listen in for connections. It's not currently
# possible to specify multiple addresses. "*" listens in all IPv4
interfaces.
# "[::]" listens in all IPv6 interfaces, but may also listen in all IPv4
# interfaces depending on the operating system. You can specify ports with
# "host:port".
imap_listen = [::]
pop3_listen = [::]
# IP or host address where to listen in for SSL connections. Defaults
# to above non-SSL equilevants if not specified.
#imaps_listen =
#pop3s_listen =
# Disable SSL/TLS support.
#ssl_disable = no
# PEM encoded X.509 SSL/TLS certificate and private key. They're opened
before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
#ssl_cert_file = /usr/share/ssl/certs/dovecot.pem
#ssl_key_file = /usr/share/ssl/private/dovecot.pem
# SSL parameter file. Master process generates this file for login
processes.
# It contains Diffie Hellman and RSA parameters.
#ssl_parameters_file = /var/run/dovecot/ssl-parameters.dat
# How often to regenerate the SSL parameters file. Generation is quite CPU
# intensive operation. The value is in hours, 0 disables regeneration
# entirely.
#ssl_parameters_regenerate = 24
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and
# IPv6 ::1 addresses are considered secure, this setting has no effect if
# you connect from those addresses.
disable_plaintext_auth = no
# Use this logfile instead of syslog(). /dev/stderr can be used if you
want to
# use stderr for logging (ONLY /dev/stderr - otherwise it is closed).
#log_path =
# For informational messages, use this logfile instead of the default
#info_log_path =
# Prefix for each line written to log file. % codes are in strftime(3)
# format.
#log_timestamp = "%b %d %H:%M:%S "
##
## Login processes
##
# Directory where authentication process places authentication UNIX sockets
# which login needs to be able to connect to. The sockets are created when
# running as root, so you don't have to worry about permissions. Note that
# everything in this directory is deleted when Dovecot is started.
login_dir = /var/run/dovecot-login
# chroot login process to the login_dir. Only reason not to do this is
if you
# wish to run the whole Dovecot without roots.
#login_chroot = yes
##
## IMAP login process
##
login = imap
# Executable location.
#login_executable = /usr/libexec/dovecot/imap-login
# User to use for the login process. Create a completely new user for this,
# and don't use it anywhere else. The user must also belong to a group where
# only it has access, it's used to control access for authentication
process.
#login_user = dovecot
# Set max. process size in megabytes. If you don't use
# login_process_per_connection you might need to grow this.
#login_process_size = 32
# Should each login be processed in it's own process (yes), or should one
# login process be allowed to process multiple connections (no)? Yes is more
# secure, espcially with SSL/TLS enabled. No is faster since there's no need
# to create processes all the time.
#login_process_per_connection = yes
# Number of login processes to create. If login_process_per_user is
# yes, this is the number of extra processes waiting for users to log in.
#login_processes_count = 3
# Maximum number of extra login processes to create. The extra process count
# usually stays at login_processes_count, but when multiple users start
logging
# in at the same time more extra processes are created. To prevent
fork-bombing
# we check only once in a second if new processes should be created - if all
# of them are used at the time, we double their amount until limit set
by this
# setting is reached. This setting is used only if login_process_per_use
is yes.
#login_max_processes_count = 128
# Maximum number of connections allowed in login state. When this limit is
# reached, the oldest connections are dropped. If login_process_per_user
# is no, this is a per-process value, so the absolute maximum number of
users
# logging in actually login_processes_count * max_logging_users.
#login_max_logging_users = 256
##
## POP3 login process
##
# Settings default to same as above, so you don't have to set anything
# unless you want to override them.
login = pop3
# Exception to above rule being the executable location.
#login_executable = /usr/libexec/dovecot/pop3-login
##
## Mail processes
##
# Maximum number of running mail processes. When this limit is reached,
# new users aren't allowed to log in.
#max_mail_processes = 1024
# Show more verbose process titles (in ps). Currently shows user name and
# IP address. Useful for seeing who are actually using the IMAP processes
# (eg. shared mailboxes or if same uid is used for multiple accounts).
#verbose_proctitle = no
# Show protocol level SSL errors.
#verbose_ssl = no
# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
#first_valid_uid = 500
#last_valid_uid = 0
# Valid GID range for users, defaults to non-root/wheel. Users having
# non-valid GID as primary group ID aren't allowed to log in. If user
# belongs to supplementary groups with non-valid GIDs, those groups are
# not set.
#first_valid_gid = 1
#last_valid_gid = 0
# Grant access to these extra groups for mail processes. Typical use
would be
# to give "mail" group write access to /var/mail to be able to create
dotlocks.
#mail_extra_groups =
# ':' separated list of directories under which chrooting is allowed for
mail
# processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too).
# This setting doesn't affect login_chroot or auth_chroot variables.
# WARNING: Never add directories here which local users can modify, that
# may lead to root exploit. Usually this should be done only if you don't
# allow shell access for users. See doc/configuration.txt for more
information.
#valid_chroot_dirs =
# Default chroot directory for mail processes. This can be overridden by
# giving /./ in user's home directory (eg. /home/./user chroots into /home).
#mail_chroot =
# Default MAIL environment to use when it's not set. By leaving this empty
# dovecot tries to do some automatic detection as described in
# doc/mail-storages.txt. There's a few special variables you can use:
#
# %u - username
# %n - user part in user@domain, same as %u if there's no domain
# %d - domain part in user@domain, empty if user there's no domain
# %h - home directory
#
# You can also limit a width of string by giving the number of max.
characters
# after the '%' character. For example %1u gives the first character of
# username. Some examples:
#
# default_mail_env = maildir:/var/mail/%1u/%u/Maildir
# default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u
# default_mail_env = mbox:/var/mail/%d/%n/:INDEX=/var/indexes/%d/%n
#
#default_mail_env =
# Space-separated list of fields to cache for all mails. Currently these
# fields are allowed followed by a list of commands they speed up:
#
# Envelope - FETCH ENVELOPE and SEARCH FROM, TO, CC, BCC, SUBJECT,
# SENTBEFORE, SENTON, SENTSINCE, HEADER MESSAGE-ID,
# HEADER IN-REPLY-TO
# Body - FETCH BODY
# Bodystructure - FETCH BODY, BODYSTRUCTURE
# MessagePart - FETCH BODY[1.2.3] (ie. body parts), RFC822.SIZE,
# SEARCH SMALLER, LARGER, also speeds up BODY/BODYSTRUCTURE
# generation. This is always set with mbox mailboxes, and
# also default with Maildir.
#
# Different IMAP clients work in different ways, that's why Dovecot by
default
# only caches MessagePart which speeds up most operations. Whenever client
# does something where caching could be used, the field is automatically
marked
# to be cached later. For example after FETCH BODY the BODY will be cached
# for all new messages. Normally you should leave this alone, unless you
know
# what most of your IMAP clients are. Caching more fields than needed makes
# the index files larger and generate useless I/O.
#
# With maildir there's one extra optimization - if nothing is cached,
indexing
# the maildir becomes much faster since it's not opening any of the mail
files.
# This could be useful if your IMAP clients access only new mails.
#mail_cache_fields = MessagePart
# Space-separated list of fields that Dovecot should never set to be cached.
# Useful if you want to save disk space at the cost of more I/O when the
fields
# needed.
#mail_never_cache_fields =
# Workarounds for various client bugs:
# oe6-fetch-no-newmail:
# Never send EXISTS/RECENT when replying to FETCH command. Outlook
Express
# seems to think they are FETCH replies and gives user "Message no
longer
# in server" error. Note that OE6 still breaks even with this workaround
# if synchronization is set to "Headers Only".
# outlook-idle:
# Outlook and Outlook Express never abort IDLE command, so if no mail
# arrives in half a hour, Dovecot closes the connection. This is still
# fine, except Outlook doesn't connect back so you don't see if new mail
# arrives.
# outlook-pop3-no-nuls:
# Outlook and Outlook Express hang if mails contain NUL characters.
# This setting replaces them with 0x80 character.
#client_workarounds =
# Dovecot can notify client of new mail in selected mailbox soon after it's
# received. This setting specifies the minimum interval in seconds between
# new mail notifications to client - internally they may be checked more or
# less often. Setting this to 0 disables the checking.
# NOTE: Evolution client breaks with this option when it's trying to APPEND.
#mailbox_check_interval = 0
# Like mailbox_check_interval, but used for IDLE command.
#mailbox_idle_check_interval = 30
# Allow full filesystem access to clients. There's no access checks
other than
# what the operating system does for the active UID/GID. It works with both
# maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/
# or ~user/.
#mail_full_filesystem_access = no
# Maximum allowed length for custom flag name. It's only forced when trying
# to create new flags.
#mail_max_flag_length = 50
# Save mails with CR+LF instead of plain LF. This makes sending those mails
# take less CPU, especially with sendfile() syscall with Linux and FreeBSD.
# But it also creates a bit more disk I/O which may just make it slower.
#mail_save_crlf = no
# Use mmap() instead of read() to read mail files. read() seems to be a bit
# faster with my Linux/x86 and it's better with NFS, so that's the default.
#mail_read_mmaped = no
# By default LIST command returns all entries in maildir beginning with dot.
# Enabling this option makes Dovecot return only entries which are
directories.
# This is done by stat()ing each entry, so it causes more disk I/O.
# (For systems setting struct dirent->d_type, this check is free and it's
# done always regardless of this setting)
#maildir_stat_dirs = no
# Copy mail to another folders using hard links. This is much faster than
# actually copying the file. This is problematic only if something modifies
# the mail in one folder but doesn't want it modified in the others. I don't
# know any MUA which would modify mail files directly. IMAP protocol also
# requires that the mails don't change, so it would be problematic in
any case.
# If you care about performance, enable it.
#maildir_copy_with_hardlinks = no
# Check if mails' content has been changed by external programs. This slows
# down things as extra stat() needs to be called for each file. If
changes are
# noticed, the message is treated as a new message, since IMAP protocol
# specifies that existing messages are immutable.
#maildir_check_content_changes = no
# Which locking methods to use for locking mbox. There's three available:
# dotlock: Create <mailbox>.lock file. This is the oldest and most NFS-safe
# solution. If you want to use /var/mail/ like directory, the
users
# will need write access to that directory.
# fcntl : Use this if possible. Works with NFS too if lockd is used.
# flock : May not exist in all systems. Doesn't work with NFS.
#
# You can use both fcntl and flock too; if you do the order they're declared
# with is important to avoid deadlocks if other MTAs/MUAs are using both
fcntl
# and flock. Some operating systems don't allow using both of them
# simultaneously, eg. BSDs. If dotlock is used, it's always created first.
mbox_locks = fcntl
# Should we create dotlock file even when we want only a read-lock? Setting
# this to yes hurts the performance when the mailbox is accessed
simultaneously
# by multiple processes, but it's needed for reliable reading if no other
# locking methods are available.
#mbox_read_dotlock = no
# Maximum time in seconds to wait for lock (all of them) before aborting.
#mbox_lock_timeout = 300
# If dotlock exists but the mailbox isn't modified in any way, override the
# lock file after this many seconds.
#mbox_dotlock_change_timeout = 30
# umask to use for mail files and directories
#umask = 0077
# Drop all privileges before exec()ing the mail process. This is mostly
# meant for debugging, otherwise you don't get core dumps. Note that setting
# this to yes means that log file is opened as the logged in user, which
# might not work. It could also be a small security risk if you use
single UID
# for multiple users, as the users could ptrace() each others processes
then.
#mail_drop_priv_before_exec = no
##
## IMAP process
##
# Executable location
#imap_executable = /usr/libexec/dovecot/imap
# Set max. process size in megabytes. Most of the memory goes to mmap()ing
# files, so it shouldn't harm much even if this limit is set pretty high.
#imap_process_size = 256
# Support for dynamically loadable modules.
#imap_use_modules = no
#imap_modules = /usr/lib/dovecot/imap
##
## POP3 process
##
# Executable location
#pop3_executable = /usr/libexec/dovecot/pop3
# Set max. process size in megabytes. Most of the memory goes to mmap()ing
# files, so it shouldn't harm much even if this limit is set pretty high.
#pop3_process_size = 256
# Support for dynamically loadable modules.
#pop3_use_modules = no
#pop3_modules = /usr/lib/dovecot/pop3
##
## Authentication processes
##
# An Authentication process is a child process used by Dovecot that
# handles the authentication steps. The steps cover an authentication
# mechanism (auth_mechanisms, how the client authenticates in the IMAP or
# POP3 protocol), which password database should be queried (auth_passdb),
# and which user database should be queried (auth_userdb, to obtain
# UID, GID, and location of the user's mailbox/home directory).
#
# You can have multiple processes, though a typical configuration will
# have only one. Each time "auth = xx" is seen, a new process
# definition is started. The point of multiple processes is to be able
# to set stricter permissions. (See auth_user below.)
#
# Just remember that only one Authentication process is asked for the
# password, so you can't have different passwords accessible through
# different process definitions (unless they have different
# auth_mechanisms, and you're ok with having different password for
# each mechanisms).
# Authentication process name.
auth = default
# Specifies how the client authenticates in the IMAP protocol.
# Space separated list of permitted authentication mechanisms:
# anonymous plain digest-md5 cram-md5
#
# anonymous - No authentication required.
# plain - The password is sent as plain text. All IMAP/POP3 clients
# support this, and the password can be encrypted by Dovecot to match
# any of the encryption schemes used in password databases.
# digest-md5 and cram-md5 - both encrypt the password so it is more
# secure in transit, but are not well supported by clients, and
# require that the password database use a matching encryption
# scheme (or be in plaintext).
#
# See auth.txt for more details.
#
# If you are using SSL there is less benefit to digest-md5 and
# cram-md5 as the communication is already encrypted.
auth_mechanisms = plain
# Space separated list of realms for SASL authentication mechanisms that
need
# them. You can leave it empty if you don't want to support multiple realms.
# Many clients simply use the first one listed here, so keep the default
realm
# first.
#auth_realms =
# Default realm/domain to use if none was specified. This is used for both
# SASL realms and appending @domain to username in plaintext logins.
#auth_default_realm =
# Where user database is kept:
# passwd: /etc/passwd or similiar, using getpwnam()
# passwd-file <path>: passwd-like file with specified location
# static uid=<uid> gid=<gid> home=<dir template>: static settings
# vpopmail: vpopmail library
# ldap <config path>: LDAP, see doc/dovecot-ldap.conf
# pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf
auth_userdb = passwd
# Where password database is kept:
# passwd: /etc/passwd or similiar, using getpwnam()
# shadow: /etc/shadow or similiar, using getspnam()
# pam [<service> | *]: PAM authentication
# passwd-file <path>: passwd-like file with specified location
# vpopmail: vpopmail authentication
# ldap <config path>: LDAP, see doc/dovecot-ldap.conf
# pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf
#auth_passdb = pgsql /usr/local/etc/dovecot-pgsql.conf
auth_passdb = pam
#auth_executable = /usr/libexec/dovecot/dovecot-auth
# Set max. process size in megabytes.
#auth_process_size = 256
# User to use for the process. This user needs access to only user and
# password databases, nothing else. Only shadow and pam authentication
# requires roots, so use something else if possible. Note that passwd
# authentication with BSDs internally accesses shadow files, which also
# requires roots.
auth_user = root
# Directory where to chroot the process. Most authentication backends don't
# work if this is set, and there's no point chrooting if auth_user is root.
#auth_chroot =
# Number of authentication processes to create
#auth_count = 1
# List of allowed characters in username. If the user-given username
contains
# a character not listed in here, the login automatically fails. This is
just
# an extra check to make sure user can't exploit any potential quote
escaping
# vulnerabilities with SQL/LDAP databases. If you want to allow all
characters,
# set this value to empty.
#auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
# Username to use for users logging in with ANONYMOUS SASL mechanism
#auth_anonymous_username = anonymous
# More verbose logging. Useful for figuring out why authentication isn't
# working.
#auth_verbose = no
# Even more verbose logging for debugging purposes. Shows for example SQL
# queries.
#auth_debug = no
# digest-md5 authentication process. It requires special MD5 passwords which
# /etc/shadow and PAM doesn't support, so we never need roots to handle it.
# Note that the passwd-file is opened before chrooting and dropping root
# privileges, so it may be 0600-root owned file.
#auth = digest_md5
#auth_mechanisms = digest-md5
#auth_realms =
#auth_userdb = passwd-file /etc/passwd.imap
#auth_passdb = passwd-file /etc/passwd.imap
#auth_user = imapauth
#auth_chroot =
# if you plan to use only passwd-file, you don't need the two auth
processes,
# simply set "auth_methods = plain digest-md5"
20 years, 10 months
Re: [CentOS] Dell Dimension 2400 W/Intel 845-G Video(SOLVED)
by Mark LaPierre
Hey Todd,
Thanks for the excellent tip. I followed your instructions to log in
and then log out to restart GDM. It worked great. Now I've got a
screen resolution of 1280 x 1024 with all the little letters right where
you would expect them to be.
I installed the elrepo then installed the kernel. I had to edit
/boot/grub/menu.list to make the new kernel the default but that's all
it took. Life is good and I can stop messing with this old clunker and
return it to it's rightful owner for resale.
--
_
°v°
/(_)\
^ ^ Mark LaPierre
Registered Linux user No #267004
https://linuxcounter.net/
****
On 11/03/14 09:46, Denniston, Todd A CIV NAVSURFWARCENDIV Crane wrote:
> Here is some hope for you.
> I too have been fighting with an intel 845G, but mine is in an IBM built machine.
> I just loaded the elrepo kernel-ml on a CentOS 6.6 system with an intel 845-G and now the X comes up correctly, i.e., at boot gdm is available visually for login. YYEEESS!!!
>
> With either kernel, if you want any GL performance, you do _not_ want to use nomodeset, i.e., with nomodeset tux racer renders ~1FPS @800x600. Vesa is in the same boat and eats your main cpu to render anything.
>
> With the standard _2.6_ kernels with CentOS 6.[56], even though the screen was blank (but with a mouse pointer) you could log in by simply typing the first letter of your username, press enter, enter your password, press enter, then wait for login, and because characters were messed up logout, at which point the restarted gdm and X would be working fine and you could login for a nice session.
> Found this trick somewhere in the archives of this list IIRC.
> Note:` telinit 3; telinit 5` OR `killall gdm-binary` do *NOT* help.
>
> I don't have an xorg.conf or anything in xorg.conf.d, and I don't have any changes to the kernel line since install, i.e., using CentOS defaults.
>
> With the elrepo kernel-ml, it does seem like there is a little more load on the system, but login has become normal and I see ~14FPS in tux racer @800x600 (OK it is not a speed daemon, but at least it is smoothed). After login the screen res defaults to 1920x1080 IIRC.
> After login I have been using xrandr to change the screen res I want for each task (many web sites don't look right at anything above 1024x768).
> xrandr -q #to see available sizes
> and
> xrandr -s 1024x768
>
> good luck, and if this works for you and/or you find a better way, please let us know.
>
> Even when this disclaimer is not here:
> I am not a contracting officer. I do not have authority to make or modify the terms of any contract.
>
>> -----Original Message-----
>> From: Mark LaPierre [mailto:marklapier@gmail.com]
>> Sent: Sunday, November 02, 2014 9:35 PM
>> To: Mark LaPierre; Mail List CentOS Users
>> Subject: Re: [CentOS] Dell Dimension 2400 W/Intel 845-G Video
>>
>> On 10/05/14 22:47, Mark LaPierre wrote:
>>> Hey Y'all,
>>>
>>> I've been Googeling and experimenting for two days trying to find a way
>>> to deal with the Intel 845-G video chipset in this Dell Dimension 2400.
> <SNIP>
>>>
>>> There's a lot a cruft on the internet about problems with the Intel
>>> 845-G chipset but no solutions that work for me. Does anyone know
>>> how to get an successful installation on this hardware?
>>>
>>
>> First I want to thank all of you who have offered up proposed solutions.
>>
>> I got the netinstall to work. Then used yum update to bring it up to
>> the latest and greatest. I worked with 6.5 but got nowhere there. Then
>> the 6.6 point release was ready so I did the yum update dance in hopes
>> that 6.6 would be more cooperative.
>>
>> Today I've been googling, experimenting, and pretty much failing
>> miserably. The best I've managed to get is to set the boot command to
>> nomodeset, and the xorg.conf "Device" driver to vesa. I got 640x480
>> resolution with the image offset to the left and down. Pretty much
>> unusable. No improvement from my previous best effort documented above.
>>
>> I am able to open System/Preferences/Display where I could select a
>> different resolution if I could see and reach the [Apply] button. That
>> really doesn't matter since the only resolution available on the pull
>> down is 640x480.
>>
>> I can't get the intel driver to yield a screen at all.
>>
>> I experimented with many VGA=NNN modes in combination with the vesa
>> driver. No joy there. Not even the GDM screen comes up. The best I've
>> been able to get from the intel driver is a mouse pointer in the middle
>> of an otherwise black screen.
>>
>> When the graphics come up I can check the Xorg.0.log where I can see
>> that the vesa driver says that resolutions including 1280x1024, 104x768,
>> and 800x600 are viable options. I can't get it to use any of them.
>>
>> What think yee? Is there any hope of getting any resolution greater
>> than 640x480 out of this thing?
>>
>> --
>> _
>> °v°
>> /(_)\
>> ^ ^ Mark LaPierre
>> Registered Linux user No #267004
>> https://linuxcounter.net/
>> ****
>
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
11 years, 4 months