On 02/02/18 10:09, Felipe Westfields wrote:
> I would like to be able to allow regular users that don't have admin
> privileges to be able to reboot their workstation. (they're software
> developers so rebooting their workstation doesn't affect anybody else)
>
> I tried changing the ownership of /sbin/reboot and /sbin/shutdown to
> root:users and permissions to 550, but that didn't work - it's still asking
> for root privileges.
>
> Possibly the problem might be that there's centralized LDAP authentication,
> not local, so the changes I made only apply to local accounts?
>
> Any suggestions?
If they are local users (sitting in front of that computer), they will
be able to use the commands
shutdown
reboot
poweroff
without any need of special privileges, which tells RedHat and CentOS
apart from majority of Linuxes. This is incredibly logical (Thanks,
RedHat!), as local user can just press power button, or yank AC cord.
To allow remote users reboot machine you can allow them execute some
commands via sudo , like:
sudo reboot
Command sudo means Substitute User DO; when username of substitute user
is not mentioned in command user "root: is used as substitute user, this
is where misinterpreting the command as "super user do" originates, and
the last is wrong. Do "man visudo", "man sudo", to learn details.
Incidentally, rebooting machine is rather big deal, if that is used to
resolve some trouble happening every so often, I would rather look into
fixing the cause of that trouble.
Valeri
>
> FW
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I am new to Linux so I do not have any special preferences.
Yes I have a root access and the VPS is un managed.
I am newbie to the Linux world.
I will have a new website or maybe 3.
I've found that un managed costs vary a lot, as I've found various ways
for settings ... some using Xen, others using OpenVZ, and other using
Virtuozzo and I found that it all vary regarding Ram allocations for
each VPS.
Also afraid to stuck with some over sell VPS as I had it before with
shared hosting.
For un managed hosting VPS will it be easy to secure the server from
being hacked? or it is an impossible job for a newbie guy like me?
Also for later on regarding updates or patching ... will it be good as
well or not?
Finally I've found most people using Ubuntu server LTS, so do you advise
of using it or any other distribution?
I've read a lot of reviews that most are advising for using CentOS or
Debian, but I've found the majority are already using Ubuntu server.
Thanks and too much appreciated your time reading and value your inputs.
Note:
After a lot of reading I've found that the steps should be as follow:
(the funny thing that I've read and know what I should do but each time
I am trying to run a command using PUTTY I get an error)
- change root password to a secure one.
- create another user with admin access with a strong password as well.
- disable root remotely access.
- use secure connection to the VPS by using PUTTY key instead of
username and password login .
- change the port to a high one with unusual figure like 26127 or any else
- disable ftp and use another secure one.
- install a fire wall, CSF firewall and Mod_security or anything else
equal or more.
- keep the whole thing up-to-date.
- secure the whole VPS as much as possible.
- finally use a trusted script on the website and his why I will use
Drupal (mostly the core ones and nothing else without any modules).
This is what I've got so far from reading many tutorials and still get a
lot of errors when I follow them (howtoforge.com) is one of the famous
websites I've visited.
Sorry for being long ... But I am really hope if you here be able to
help or guide me.
- Late Edit -
I've forget to mention that some steps I've forget to mention are:
- using back ed control panel (like ISP config, VirtualMin) is
facilitating the task but make VPS less secure, so using the command .
On Fri, 17 Sep 2010, Michel van Deventer wrote:
> >
> > (another in an ongoing list of things i just want to clarify for the
> > sake of future courses taught on centos.)
> >
> > from this RHEL doc page:
> >
> > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deploymen…
> >
> > the reader is advised to, for the sake of security, remove/disable
> vsftpd, ostensibly in favour of sftp/sftp-server. really?
> >
> > i can obviously see disallowing stuff like telnet and rsh and
> > rlogin, that's a no-brainer. but advising against vsftpd for the sake
> of security? i'm not sure i see the logic in that. thoughts?
> As FTP is a clear-text protocol, I would surely advise against
> leaving it on :) I only run a vsftpd server on one of my machines
> for the customers comfort, but that will change in the near future !
>
> I can easily image scenarios where unencrypted traffic with
> usernames/passwords is disallowed.
but you can configure vsftpd to have secure connection:
http://wiki.vpslink.com/Configuring_vsftpd_for_secure_connections_(TLS/SSL/…
would that not address that issue? i'm not arguing against secure
communications, only that that manual page so cavalierly dismisses
vsftpd when it seems clear that you *can* configure vsftpd to be
secure.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
Ramon Nieto wrote:
>
>
> --- El *mié 2-jul-08, Robert Moskowitz /<rgm(a)htt-consult.com>/* escribió:
>
> De:: Robert Moskowitz <rgm(a)htt-consult.com>
> Asunto: [CentOS] PPPoE setup
> A: "CentOS mailing list" <centos(a)centos.org>
> Fecha: miércoles, 2 julio, 2008, 4:09 pm
>
> My provider is getting ready to switch my DSL router to bridging mode
> and I supply the router (so I can get no only IPv4 addresses but also
> IPv6 addresses!).
>
> Here are his 'instructions' to me:
>
> "Basically you start pppoe, I give you the username and password for it,
> and then I set the router to passthrough
> modem mode, and you initiate
> the PPPoE session directly with my LNS back here. You'll get a dynamic
> IP on the dsl side
> (which is normal) and then you just set up your
> static routes in the linux box as normal. My LNS automatically routes
> your traffic to the IP it randomly assigns to the DSL link. Once we
> verify that IP6CP is up, I can assign you a /48 and you can rock out
> with that however you want."
>
>
>
> Currently I have a /26 IPv4 assignment which will continue.
>
> So do I change the alias in modprobe.conf from eth0 to ppp0? Or is just
> listing interface eth0 in hte pppoe.conf file enough?
>
> From my ISP's comments, the pppoe negotiation will provide the address
> for eth0. I already know my /26 allocation. I need to set up static
> routes on eth1 for these IPv4 addresses (different subnets to different
> internal firewalls). What tool do I use to set these?
>
> And then I get to work with
> IPv6!
>
> Pointers to Howtos are greatly appreciated.
>
>
>
> _______________________________________________
> CentOS
> mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>
>
> Robert,
>
> No, do not modify the alias for eth0, leave modprobe.conf unchanged.
>
OK. That is what I thought. I suspect the advice I found was for a
different distro.
>
> How did you configured the pppoe link?
>
I haven't yet. Trying to get the steps down before I do. Once I start,
I am off the net until it works.
>
> I have been using the adsl-setup command from the rp-pppoe package to
> configure the dsl link, it generates the ifcfg-ppp0 file on
> /etc/sysconfig/network/scripts with the values needed to bring the
> link up such as the username, network interface to use, etc.
>
> Also the adsl-setup command stores the username and password on the
> chap-secrets and pap-secrets files under /etc/ppp
>
> After the dsl is configured you can bring it up /down with the
> adsl-start adsl-stop commands.
>
>
OK. I see the adsl-setup command in both /sbin and /usr/sbin. So I can
run them and see what they produce.
What do you do to get adsl-start to run at boot (and at the proper point
in booting).
Hi All.
I am working on bringing back a number of Centos 7 rigs in our student computer lab back online. No change was made to the existing server machine [running Scientific Linux 6]
Right now there is one remaining thing to resolve: an inconsistency with the rigs' NIS Clients.
I have configured rcpbind and ypbind following guidance from Server World ( https://www.server-world.info/en/note?os=CentOS_7&p=nis&f=2 ) identically on all of the client machines. I have done this before with previous installs before this. The last time was this summer. Three are behaving as they are supposed to do. Five, however, are not.
In this process I have repeatedly checked that support files ..
/etc/sysconfig/network
/etc/yp.conf
/etc/pam.d/system-auth-ac
/etc/pam.d/system-auth
/etc/login.defs
/etc/sysconfig/authconfig
They are identical.
IP addresses, Netmasks, Gateways, DNS, etc. are correct and all rigs (Server and Clients) do not conflict on any of the machines or /etc/host files.
Disabling firewalls don’t impact the problem.
NFS and other services work fine. All other aspects of networking is fine. You can ssh and access the Server rig from the Client rigs and for locally installed accounts on the clients go the other way. Accounts that leverage NIS cannot log into the Client from the Server or any other remote system.
rpcbind shows that the ypbind/ypserv services are up and Clients and Server, respectfully (and it works on some of the machines).
The rigs that are not working exhibit the following (satisfactory) behavior.
* yptest -u [valid nis username] works with no errors.
* yppasswd will change a password on the NIS server with no errors and other commands like ypchfn will work as well.
* ypwhich, ypcat, ypmap, etc. give the same values we'd see on the NIS server.
...BUT...
* You cannot console-login, ssh, or su into the rigs with valid NIS accounts.
* (The local ypbind -d "debug mode" shows no response to a login, the "secure" log responds to a valid NIS account login with an "invalid user" a the [preauth] phase)
* uids of valid NIS users are not recognized.
* With ls -l, we see the uid of a file’s owner and not the username. (gids are explicitly declared locally on all rigs so they’ll match anyway.)
* The id command for any valid nis user fails with "no such user"
* cd ~[Valid NIS User] responds with "no such directory" even if the home directory exists (and the uid matches the uid on the NIS server).
I am totally at a loss here. I cannot see the difference in what I did on the machines that work and the machines that do not work.
Is there any test that I am missing or are there any files or setting where the culprit(s) on the errant machines may be?
Cheers and Thanks
---------------------------------------------------------------------------------------
Dr. Bill Capehart <William.Capehart(a)sdsmt.edu<mailto:William.Capehart@sdsmt.edu>>
Director, Atmospheric and Environmental Sciences Program
Department of Civil and Environmental Engineering
201 Mineral Industries Building (MWRF)
123 Civil Mechanical Building (T)
South Dakota School of Mines and Technology
501 East St Joseph Street
Rapid City, SD 57701-3995 USA
Ph: +1-605-394-1994 Mobile: +1-605-484-5692
Cameron Smith <cameron(a)networkredux.com> writes:
> There are seven fields on each line in a typical Linux "/etc/passwd" file.
>
> For a line that looks like this:
> root:x:0:0:root:/root:/bin/bash
>
> 1. root: Account username.
> 2. x: Placeholder for password information. The password is obtained from
> the "/etc/shadow" file.
> 3. 0: User ID. Each user has a unique ID that identifies them on the
> system. The root user is always referenced by user ID 0.
> 4. 0: Group ID. Each group has a unique group ID. Each user has a "primary"
> group that is used as the group by default. Again, the root group's ID is
> always 0.
> 5. root: Comment field. This field can be used to describe the user or
> user's function. This can be anything from contact information for the
> user, to descriptions of the service the account was made for.
> 6. /root: Home directory. For regular users, this would usually be
> "/home/username". For root, this is "/root".
> 7. /bin/bash: User shell. This field contains the shell that will be
> spawned or the command that will be run when the user logs in.
>
> I would take a look at that user's line in /etc/passwd and see what their
> home directory is set to.
The user is set up correctly. Nothing changed other than that the disks
holding the directory are now in the server rather than in the client,
exported from the server via nfs and mounted through an fstab entry on
the client.
I´m using this right now, and it works fine other than the user not
ending up in the home directory and emacs not applying everything from
~/.emacs.
As far as I can tell, what is not applied is
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(default ((t (:inherit nil :stipple nil :background "black" :foreground "green" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 78 :width normal :foundry "unknown" :family "DejaVu Sans Mono")))))
which is the second last line in ~/.emacs. Perhaps there´s more which
is not applied without me noticing yet. However, there could be another
reason for that; I´ll have to figure that out later.
--
"Didn't work" is an error.
On 08/02/2012 09:07 AM, Paul R. Ganci wrote:
> On 08/01/2012 09:13 AM, Andreas Rogge wrote:
>> Am 01.08.2012 09:39, schrieb Paul R. Ganci:
>>> anybody have a clue as to why %u is not evaluating to the linux username
>>> snichols and is getting treated simply as the string %u?
>> You have to use %U instead of %u - this is not a security issue as
>> having the wrong UNC path should (and probably will) be caught using ACLs.
> Well last night I implemented this change and indeed this fixed the Win
> XP problem. The domain users on the client Win XP box can indeed find
> their roaming profiles and properly sync them at logon/logoff time.
> However when I went to add a domain user to the first Win 7 Professional
> box added to the domain, that user only gets a local profile (i.e. a
> C:\Users\username instead of C:\Users\username.domainame) despite the
> fact the domain user has a roaming profile. I am sure this is a Win 7
> client setup issue.
>
> The best I have been able to do is copy a local profile from the Win 7
> box for the domain user back to the Samba PDC. I then delete the domain
> user's local profile and could get the Win 7 client to read the profile
> from the Samba PDC on the domain user's next logon. Basically I can get
> the Win 7 client to create a new local profile from the profile found on
> the Samba PDC but on logoff the Win 7 client will not sync that profile
> with the Samba PDC and on subsequent logons only uses the local stored
> profile on the Win 7 box. It is like the Win 7 client policy is to use
> local profiles only and it uses the Samba PDC profile only as a default
> if the local profile doesn't exist. There is no subsequent profile
> synchronization at logon/logoff after the Win 7 local profile gets created.
>
> Any suggestions to registry/policy settings to get roaming profiles to
> act as roaming profiles on a Win 7 Professional SP 1 box? I thought I
> ask here first as I am already on this list. Admittedly this might
> better belong on a Samba forum but I am guessing somebody out there has
> already run into this issue. Everything on the web says this should work
> but alas...
Are you adding all of the required registry entries on the Win7 machines
to have them join the domain?
http://wiki.samba.org/index.php/Windows7
> You might want to take a look at "Integrating Red Hat Enterprise Linux 6 with Active Directory". It's the best document I've seen on this topic. I found that Samba/Kerberos/Winbind is the most complete solution for attaching a Samba fileserver in my AD environment. https://access.redhat.com/sites/default/files/attachments/rhel-ad-integrati…
I already figured it out earlier this afternoon and have a working setup. Will review the above.
[your setup instructions]
Here, I'm not modifying any of the hosts/resolv.conf/nsswitch.conf files. This is not an integration exercise, only a samba fileserver with AD auth.
> If you are editing a smb.conf file of a previously existing Samba fileserver, do not change the range value in the "idmap config * : range =" parameter
winbindd(8) mentions "netlogon proxy only mode", so I commented out all the range settings (after first verifying that it worked with them).
> 3. Start the smb and winbind services:
I find it will not work without nmb.
> 6. Verify the bind to AD is valid:
> a. net ads info
> b. net ads testjoin
Brilliant, I didn't know these commands.
> 7. Create a Kerberos /etc/krb5.keytab file:
> net ads keytab create -U username
> 8. Verify the contents of the Kerberos keytab file:
> klist -ke
This is a step I was missing. What is the purpose of the keytab? Can it help with the default ticket FILE:/tmp/krb5cc_0 expiration?
I'm also facing this problem, although everything seems to work fine. I've tested with smbclient and a Windows client.
# net ads testjoin
gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: No credentials cache found]
Join is OK
#
On Thu, 21 Jul 2011 16:17:10 -0400
fred smith <fredex(a)fcshome.stoneham.ma.us> wrote:
> In later Fedora releases, GDM has become less and less functional:
> configurability has been removed, more so as releases occur. From my
> (known to be flaky) memory, that includes the ability to turn off the
> silly list that exposes usernames right on the login screen, the
> ability to assign your own wallpaper to the login screen, among other
> things.
There is a gconf setting to turn off the list of users. I've haven't
tried it under CentOS 6, but it works under Fedora 14. I don't know
how to fix the wallpaper except by changing the picture behind RPM's
back. Or, up until F14, I was using a recompiled version of the
CentOS 5 gdm rpm---that might work for C6.
Fortunately, the C6 wallpaper is good enough that I don't feel compelled
to tweak it.
> In some releases you can hack your way around whatever the missing
> feature is that you're missing by using gconf-editor, in others you
> can't.
The user list preference was broken for all of Fedora 13. Blech.
There is a long open gnome bus to restore the gdm setting tool that
went away around 2.22. The chances of having it back for gnome 2 are
vanishingly small. I'm not holding my breath for the gnome 3 version
either.
> So, my guess is that RHEL/Centos 6 has inherited the later Gnome
> "features" that have removed the feature you want.
It's a sad day when Mac OS X is easier to customize than a Linux system.
Jim
i had just found that on google! way to go! thanks for the help!
On 4/13/06, Mike Kercher <mike(a)vesol.com> wrote:
> You may need to chmod 755 /home/username
>
> Mike
>
>
> > -----Original Message-----
> > From: centos-bounces(a)centos.org
> > [mailto:centos-bounces@centos.org] On Behalf Of Nick Smith
> > Sent: Thursday, April 13, 2006 10:07 AM
> > To: CentOS mailing list
> > Subject: Re: [CentOS] apache permission problems
> >
> > On 4/13/06, Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net> wrote:
> > > On Thu, 2006-04-13 at 10:45 -0400, Nick Smith wrote:
> > > > any ideas?
> > >
> > > http://fedora.redhat.com/docs/selinux-apache-fc3/
> > >
> > >
> > Im not running selinx or an selinux kernel I turned it off
> > during install, i did run the system-config-securitylevel
> > from the command line and the firewall was on, and i turned
> > if off and still nothing changed....
> > _______________________________________________
> > CentOS mailing list
> > CentOS(a)centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
--
Linux, because I'd rather own a free OS than steal one that's not
worth paying for.