On Mon, Apr 30, 2018 at 1:08 PM, Daz Day <dazday60(a)gmail.com> wrote:
> Hi,
>
> I've tried hitting up the CentOS forums and thought I'd try here too as I
> don't seem to be getting any bites.
>
> We've been in the process of migrating all our hypervisors over to CentOS 7
> using Xen. Once we had a few up and running we started to notice that the
> DomU's would randomly freeze. They become unresponsive to any network
> traffic, stop consuming CPU resources on the hypervisor and it's not
> possible to log in to the console locally using:
> virsh console <domain>
> We can sometimes get as far as typing a username and hitting return, but the
> DomU just hangs there. It doesn't seem to matter what Linux distro the DomU
> is running, it affects them all. The only way we can get them back is by
> destroying and recreating them (far from ideal!).
>
> After a bit of research and digging around, we eventually found these 2
> nuggets:
> https://wiki.gentoo.org/wiki/Xen#Xen_domU_hanging_with_kernel_4.3.2B
> https://www.novell.com/support/kb/doc.php?id=7018590
>
> They both advise adding the command line argument:
> gnttab_max_frames=256(the default is 32).
> We applied this change and all hypervisors rand stable for around a week
> until DomU's started freezing again (we've since tried even higher values,
> to no avail). More research later led me to
> https://bugs.centos.org/view.php?id=14258 and
> https://bugs.centos.org/view.php?id=14284 (which are essentially the same
> report). There hasn't really been any movement on these tickets
> unfortunately, but I have +1'd them.
>
> Have any others had issues with Xen and DomU's locking up in CentOS 7? Are
> there any other fixes/workarounds? If any additional info is needed that
> isn't already in the bug tickets or forum post, please let me know and I'll
> be happy to provide whatever is required (these freezes are happening at
> least once a day).
>
> Any help would be much appreciated and would mean my Ops guys could get a
> decent sleep!
> Cheers
> Darren
Darren,
Would you mind reposting this to xen-users, along with:
* The config file for your guests
* The output of `dmesg` from inside one of the guests before it hangs
* The output of `dmesg` run on your dom0 after one of these machine hangs
Thanks,
-George
-----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-----
> -----Original Message-----
> From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of david
> Sent: Tuesday, November 14, 2017 9:11 PM
> To: CentOS mailing list <centos(a)centos.org>
> Subject: [CentOS] Samba help
>
> Folks
>
> I have a Centos7 system (SOFA) and want to install a Samba share
> named "STUFF" for the machines inside my home. All users in my home
> have read access to the share, but only one user "me" has write
> permission. The configuration below worked just fine when the Samba
> system was on Centos 6, but did not work under Centos 7. The client
> machine is Windows 10. I have changed all "private" information for
> this message.
>
> The Centos 7 machine is running with SELINUX disabled, and
> effectively without firewall.
>
> Windows network browsing finds the computer, but not the share. (it
> used to find the share with Centos 6).
>
> The server name is SOFA
> The share name is STUFF
> the Workgroup name is MYGROUP
>
> The Linux account is "melinux"
> The logon name from windows is "me"
>
> I have issued the command
> smbpass -a me
> <password-for-me>
> <password-for-me>
>
> smb.conf contains:
> ---------------------------------------------
>
> # Samba Configuration
>
> [global]
> dns proxy = no
> hosts allow = 192.168. 127. 10. localhost
> hosts deny = ALL
> log file = /var/log/samba/%m.log
> max log size = 50
> netbios name = SOFA
> printcap name = /dev/null
> printing = bsd
> security = user
> server string = Samba %v on sofa
> socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
> username map = /etc/samba/smbusers
> winbind use default domain = no
> workgroup = MYGROUP
> [STUFF]
> browsable = yes
> case sensitive = no
> comment = STUFF on sofa
> create mask = 0755
> directory mask = 0755
> force user = melinux
> guest ok = yes
> path = /home/samba-share
> write list = melinux
>
> ----------------------------------------------
>
> smbusers contains:
> ----------------------------------------------
>
> melinux = me
>
> ----------------------------------------------
>
> Where have I gone wrong? What changed from C6 to C7. Any advice
> would be appreciated.
>
> David
See if adding these under [global] helps in smb.conf:
server max protocol = SMB3
client signing = required
max protocol = SMB2
server signing = auto
client use spnego = no
client ntlmv2 auth = no
client ipc max protocol = NT1
client ipc signing = auto
idmap config * : backend = tdb
These are what I added when upgrading from C5's Samba 3 to C7's Samba 4.
Also, one of the recent Windows updates may have disabled SMBv1, here that caused the inability to 'browse' the server shares
(yet mapping a share still worked).
On Windows 7 to enable SMBv1 on the SMB client (workstations), run the following commands:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto
I don't know if they will work on Windows 10 or not.
Al
I'm sorry, I forgot to write the mail title.
I update attachment file, and download URL.
----- Original Message -----
From: <youbest(a)sina.com>
To: "centos-devel" <centos-devel(a)centos.org>
Subject: [CentOS-devel] epel-7-ppc64
Date: 2014-11-24 17:34
Hi, All
My name is Sun Haiyong, you can call me "Haiyong", I recommend a CentOS code based on PPC64 (Big Endian) Install-system and software repository:
(Install-DVD ISO) http://mirror.lemote.com/CPOS/images/CPOS-7-Installation-20141120-1.iso
(software repository) http://mirror.lemote.com/CPOS/os/
This system is based on CentOS source code, code named “CPOS”, at present, it is not a distribution, its goal is to help the community to complete the transplantation and verification of CentOS PPC64 architecture, anyone can use it derectly or to make a CentOS for PPC64 system or to verify the support for CentOS code under the PPC64.
The "CPOS" is not meant to replace CentOS with a distribution, on the contrary, CPOS hopes to help the CentOS community to accelerate the progress of PPC64 transplantation, and hope to promote the developments of PPC64 with the CentOS community together, now it is an averification system, focus on how to transplant PPC64, there may be "CentOS" the words in the system , but not mean to violate CentOS signs.
This system has completed all the code provided in CentOS 7 compilation (except the part not compatible with the PPC64), all the compiled results are stored in the software repository, but also provide the Install-system of DVD ISO format, can be installed in the IBM PowerLinux series machines, has set the appropriate the installation source after installation, you can directly use the "yum" command to do the software installation, system is also based on PPC64 and parts library compatible with the 32 bit, can be used to verify the number in RHEL 7 (PPC64) of the third party software support.
According to the CentOS 7 provides the code (http://vault.centos.org/7.0.1406/os/Source/SPackages/ ), the following is the progress of transplantation of CPOS:
1. No compiled software package(one package):
Java-1.6.0-openjdk (now the system has been transplanted with java-1.7,temporarily not necessary)
2. PPC64 architecture is not compatible software package:
biosdevname-0.5.0-10.el7.src.rpm
crash-gcore-command-1.2.1-2.el7.src.rpm
gnu-efi-3.0u-2.el7.src.rpm
ipxe-20130517-5.gitc4bce43.el7.src.rpm
latrace-0.5.11-5.el7.src.rpm
libseccomp-2.1.1-2.el7.src.rpm
memtest86+-4.20-12.el7.src.rpm
mkbootdisk-1.5.5-11.el7.src.rpm
open-vm-tools-9.4.0-3.el7.src.rpm
pesign-0.109-6.el7.src.rpm
seabios-1.7.2.2-12.el7.src.rpm
sgabios-0.20110622svn-4.el7.src.rpm
shim-0.7-5.el7.src.rpm
shim-signed-0.7-5.2.el7.centos.2.src.rpm
syslinux-4.05-8.el7.src.rpm
tboot-1.7.4-1.el7.src.rpm
x86info-1.30-6.el7.src.rpm
xorg-x11-drv-intel-2.21.15-13.el7.src.rpm
xorg-x11-drv-openchrome-0.3.3-6.el7.src.rpm
xorg-x11-drv-vmmouse-13.0.0-10.el7.src.rpm
xorg-x11-drv-vmware-13.0.1-7.el7.src.rpm
3. An increase of some PPC software package:
yaboot, powerpc-util, ppc64-util and so on.
Repositories support "mock" compiler environment, mock configuration file, see attachment file.
Use “mock" build system
1. To prepare the mock environment
yum install mock
<copy mock configuration file to /etc/mock/>
ln -sv epel-7-ppc64.cfg /etc/mock/default.cfg
useradd <username>
usermod -a -G mock <username>
newgrp mock
mock --init
2. Download the software source code package
wget http://vault.centos.org/7.0.1406/os/Source/SPackages/zlib-1.2.7-13.el7.src.…
3. The use of mock compiler software package PPC64
mock --rebuild zlib-1.2.7-13.el7.src.rpm
The default will generate the "cpos.ppc64.rpm" at the end of the file in /var/lib/mock/epel-7-ppc64/result, if you want to change to "centos.ppc64.rpm" at the end of the file, you canuse the following steps:
wget http://mirror.lemote.com/CPOS/extras/centos-release-7-0.1406.el7.centos.2.3…
mock --init --no-cleanup-after
mock --remove cpos-release
mock --install centos-release-7-0.1406.el7.centos.2.3.ppc64.rpm
mock --install setup shadow-utils
mock --cache-alterations --init --no-clean
Again using the "mock --rebuild zlib-1.2.7-13.el7.src.rpm" can generate the "centos.ppc64.rpm" at the end of the file.
Finally, welcome everybody to try it and communicate with me.
Haiyong.Sun
2014-11-24_______________________________________________
At 02:51 AM 11/15/2017, you wrote:
>El 15/11/17 a las 3:11, david escribió:
>
>>Folks
>>
>>I have a Centos7 system (SOFA) and want to
>>install a Samba share named "STUFF" for the
>>machines inside my home. All users in my home
>>have read access to the share, but only one
>>user "me" has write permission. The
>>configuration below worked just fine when the
>>Samba system was on Centos 6, but did not work
>>under Centos 7. The client machine is Windows
>>10. I have changed all "private" information for this message.
>>
>>The Centos 7 machine is running with SELINUX
>>disabled, and effectively without firewall.
>>
>>Windows network browsing finds the computer,
>>but not the share. (it used to find the share with Centos 6).
>>
>>The server name is SOFA
>>The share name is STUFF
>>the Workgroup name is MYGROUP
>>
>>The Linux account is "melinux"
>>The logon name from windows is "me"
>>
>>I have issued the command
>>Â smbpass -a me
>>Â Â Â <password-for-me>
>>Â Â Â <password-for-me>
>>
>>smb.conf contains:
>>---------------------------------------------
>>
>># Samba Configuration
>>
>>[global]
>> dns proxy                 = no
>> hosts allow               = 192.168. 127. 10. localhost
>> hosts deny                = ALL
>> log file                  = /var/log/samba/%m.log
>> max log size              = 50
>> netbios name              = SOFA
>> printcap name             = /dev/null
>> printing                  = bsd
>> security                  = user
>> server string             = Samba %v on sofa
>> socket options            =
>>TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>> username map              = /etc/samba/smbusers
>>Â winbind use default domain = no
>> workgroup                 = MYGROUP
>>[STUFF]
>> browsable     = yes
>>Â case sensitive = no
>> comment       = STUFF on sofa
>> create mask   = 0755
>>Â directory mask = 0755
>> force user    = melinux
>> guest ok      = yes
>> path          = /home/samba-share
>> write list    = melinux
>>
>>----------------------------------------------
>>
>>smbusers contains:
>>----------------------------------------------
>>
>>melinux = me
>>
>>----------------------------------------------
>>
>>Where have I gone wrong? What changed from C6
>>to C7. Any advice would be appreciated.
>>
>>David
>Is the path right? The permissions/owner/group are correct for your users?
>
>Once i got fool looking for a similar problem and the share path was wrong!
>_______________________________________________
I have verified the owner/group settings on the
share. The directory (/home/samba-share) is
drwxr-xr-x and owned by melinux and the melinux
group. There is a file in that directory, with
permissions -rwxr--r-- and the same
owner/group. I suspect that's not the problem.
David
On 06/08/2015 02:00 PM, g wrote:
>
>
> On 06/08/2015 11:34 AM, Kay Schenk wrote:
>> On 06/07/2015 11:05 PM, g wrote:
>>> On 06/07/2015 07:25 PM, Kay Schenk wrote:
>>> <<>>
>>>
>>>> So, I'm not sure how to interpret what you said. Can I get the same
>>>> results from a CentOS install using some combination of options?
>>>
>>> because your are playing with multi flavors,
>>> [i bet you like going to baskin-robbins for ice cream ;-) ]
>>> a solution for you would be what i did some years back and i was
>>> playing with diff flavors, my "/home" partition was mounted in
>>> new install as /home2 and i let installation setup a /home in /.
>>>
>>> after install and booting it, as root i moved the newly created
>>> "user" home to the /home2 directory, renamed it to the 'user-flavor',
>>> then linked that back into the install /home and renamed it to
>>> "username" and changed ownership to "user"
>>>
>>> which then gave me:
>>>
>>> /home/username --> /home2/user-flavor
>>>
> only thing that some might call a disadvatage is
> only thing that some might call a disadvatage is
> only thing that some might call a disadvatage is
>>> so that in /home2 i had:
>>>
>>> /home2/geo-fc3
>>> /geo-fc4
>>> /geo-mandrake
>>> /geo-flavor-x
> only thing that some might call a disadvatage is
> only thing that some might call a disadvatage is
>>> /geo-flavor-y
>>>
> only thing that some might call a disadvatage is
>>> i hope you can see how i did this. i am of terse thinking and
>>> do not always go into detail enough.
>>
>> Another creative approach and one I'd thought of also!
>> But...not my first choice.
>
> did you do more than just think about it?
>
> just what do you want for a 1st choice?
I think Peter addressed my concern and responded in a way that leads me
to believe a /home2 as you suggest is not necessary since it will be
bypassed in terms of any installation, which is what I want.
>
> advantages of /home2 is you have a user home directory for all your
> flavors sitting in 1 partition that will not get erased because
> you are allocating it's own mount point when you install.
I do not have and do not want one partition for my system (files). I
have ONE flavor with many partitions and mount points. A rather "old
school" approach that's worked pretty well for me all these years.
>
> because you are using thunderbird for email client, you can set up
> Mail, ImapMail, News paths in there own director,
>
> same applies to firefox bookmarks, passwords, certificates, etc.
> such as;
>
> /home/moz/
> /moz/firefox
> /moz/thunderbird
>
> then link them to your 'flavor' user directory. same goes for your
> address book files abook.mab and abook-XX.mab, and other directories
> and files that are not path critical.
>
> only thing that some might call a disadvantage is all moz progs will
> be same, unless you happen to need something in an add-on that is
> path specific.
>
> there are many other progs that are not 'hard set' with path names.
>
>
--
--------------------------------------------
MzK
"We can all sleep easy at night knowing that
somewhere at any given time,
the Foo Fighters are out there fighting Foo."
-- David Letterman
As further data points, Debian on AWS EC2 uses the 'admin' username, and
all Google-supported images on Google Compute Engine (including CentOS)
don't have a default account at all, but rather use integrated SSH key
management via our metadata server and an open source daemon we install
into the guest.
On that note, yes, we're aware of CentOS 7 - congrats to all! - and getting
ready to proceed with GCE images of that too after we run it successfully
through our test suite.
- Jimmy
On Mon, Jul 14, 2014 at 9:07 AM, Neil Wilson <neil(a)brightbox.co.uk> wrote:
>
> On 14 Jul 2014, at 16:54, Nux! <nux(a)li.nux.ro> wrote:
>
> > ----- Original Message -----
> >> From: "Karanbir Singh" <mail-lists(a)karan.org>
> >> To: centos-devel(a)centos.org
> >> Sent: Monday, 14 July, 2014 4:32:18 PM
> >> Subject: Re: [CentOS-devel] Cloud image default login
> >>
> >> On 07/14/2014 04:27 PM, Daniel Ankers wrote:
> >>> As a user, I'd like to be able to take any set of instructions about
> >>> RHEL and s/RHEL/CentOS/g and have it work (with the exception of all
> the
> >>> things people pay RedHat good money for, of course.)
> >>
> >> in the cloud images they wont, we built our own images ( always have )
> >> and have implemented our own policy.
> >>
> >> I guess once rhel images show up for opennebula and in linode, we can
> >> start trying to work together a bit more.
> >>
> >> my point really is - lets find the best place to be, without needing to
> >> just blindly work with what / where rhel is and what they are doing
> >
> > Maybe it would be good, for a while, to have both root and cloud-user
> accounts active? Not sure how this would actually work in reality (ie how
> the cloud platforms and supporting scripts would deal with it).
> >
> > In my case, building Cloudstack templates, there is a whole lot of
> people expecting root to be active, changing this behaviour would mean
> screwing them over.
> > If CentOS also has this kind of legacy problems - which I expect to be
> true - then it's something to be thinking about.
> >
> > If this is not deemed a problem, then it would be nice to have the same
> sort of consistency between RHEL, CentOS and Fedora in this regard.
> >
>
>
> The default in cloud is to have a locked root user and use sudo for root
> operations from a non-privileged user. That’s how Ubuntu does it, and it is
> how the Fedora image does it. And it is what cloud-init expects to see
> which is what will link into the public metadata systems on the public
> clouds.
>
> The default for username should really be ‘centos’ I think. That fits with
> the other distros who name the user after themselves.
>
> The other thing that needs fixing is ‘cloud-init’ which currently doesn’t
> detect Enterprise Linux clones using systems properly and makes a hash of a
> few things. I logged a bug today about it:
> https://bugs.launchpad.net/cloud-init/+bug/1341508
>
> Bear in mind that cloud-init creates the user as specified in the default
> cloud-config and locks the root user by default. The kickstart script I
> knocked together today just creates the root user with a default password,
> locks the password in the %post (to work around a limitation in anaconda
> which demands a user if you use —lock) and then leaves the user creation to
> cloud-init.
>
> That’s certainly what would make the image most useful here.
>
>
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
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.
> 4. Some users don't have physical machines, but only have virtual
> machine(s) running on office2, which also need "network" access to
> office2 files.
Again, nothing different.
> 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). 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. 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.
> 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. 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. There is also the
issue that users who have root access to their own workstation can
pretend to be any user over NFS. 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.
> 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. 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.
> 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.
--
Les Mikesell
lesmikesell(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
>
On 14 Jul 2014, at 16:54, Nux! <nux(a)li.nux.ro> wrote:
> ----- Original Message -----
>> From: "Karanbir Singh" <mail-lists(a)karan.org>
>> To: centos-devel(a)centos.org
>> Sent: Monday, 14 July, 2014 4:32:18 PM
>> Subject: Re: [CentOS-devel] Cloud image default login
>>
>> On 07/14/2014 04:27 PM, Daniel Ankers wrote:
>>> As a user, I'd like to be able to take any set of instructions about
>>> RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the
>>> things people pay RedHat good money for, of course.)
>>
>> in the cloud images they wont, we built our own images ( always have )
>> and have implemented our own policy.
>>
>> I guess once rhel images show up for opennebula and in linode, we can
>> start trying to work together a bit more.
>>
>> my point really is - lets find the best place to be, without needing to
>> just blindly work with what / where rhel is and what they are doing
>
> Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
>
> In my case, building Cloudstack templates, there is a whole lot of people expecting root to be active, changing this behaviour would mean screwing them over.
> If CentOS also has this kind of legacy problems - which I expect to be true - then it's something to be thinking about.
>
> If this is not deemed a problem, then it would be nice to have the same sort of consistency between RHEL, CentOS and Fedora in this regard.
>
The default in cloud is to have a locked root user and use sudo for root operations from a non-privileged user. That’s how Ubuntu does it, and it is how the Fedora image does it. And it is what cloud-init expects to see which is what will link into the public metadata systems on the public clouds.
The default for username should really be ‘centos’ I think. That fits with the other distros who name the user after themselves.
The other thing that needs fixing is ‘cloud-init’ which currently doesn’t detect Enterprise Linux clones using systems properly and makes a hash of a few things. I logged a bug today about it: https://bugs.launchpad.net/cloud-init/+bug/1341508
Bear in mind that cloud-init creates the user as specified in the default cloud-config and locks the root user by default. The kickstart script I knocked together today just creates the root user with a default password, locks the password in the %post (to work around a limitation in anaconda which demands a user if you use —lock) and then leaves the user creation to cloud-init.
That’s certainly what would make the image most useful here.