Monthly Archives: October 2015

Want to use DNF? What to expect…

DNF actually DOES stand for something… Not sure where that started.

DNF stands for Dandified yum

DNF started showing up in Fedora 18, and Fedora 20 was the first Linux distro that welcomed users to utilize  DNF in place of YUM.

The technical challenges of DNF are that there is little or no support for features:

  • Debug
  • Verbose output
  • Enable Repository
  • Exclude packages during install
  • No effect of –skip-broken switch
  • The command resolvedep unavailable
  • The option skip_if_unavailable is ON by default
  • Dependency resolving process is not visible in Command Line
  • Parallel downloads in future release
  • Undo History
  • Delta RPM
  • Bash completion
  • Auto-remove
  • many others…

 

In short, if you drink the cool-aid then you should run this in a lab only.  I know people that try to run this stuff in production.  You are just asking for a serious problem. Other than that, I hope it gets there, DNF is just too new.

who did what with ROOT?!

When you are not sure who is using SUDO on a server, and you really need to know who keeps making that annoying change.  You can install something to watch them, and maintain that software and related logs. Keep it setup in your package management system, and make sure it doesn’t have any patches.

OR

You could use the little-known (at least those I have asked in the field) modifications I will list below.  They are two fold.  One, you will enable to record who logs in and uses SUDO, and records their session. Much like many pieces of software out there today.  The one catch to my method is simple.  You already have the software installed, yup this has been a feature of SUDO since version 1.7.4p4.  So nothing else to install, worry about, or maintain.  It is also very easy to setup, see below:


/etc/sudoers modifcation:
All you need to do is to add 2 tags to all required sudoers entries.
*(where "su" specified, either with command or alias). 
LOG_INPUT and LOG_OUTPUT
Example: 
%admins ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL

Add the following default log dir structure to sudoers:
Defaults iolog_dir=/var/log/sudo-io/%{user}
Note:
Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=.  The iolog_file option may be used to control the format of the session ID.  Output logs may be viewed with the
sudoreplay(8) utility, which can also be used to list or search the available logs.   Keeping in mind that if the user has a really long session you will be viewing it like a movie, it will replay as if he is sitting there typing.  With this in mind, sudoreplay gives you the ability to play back at faster speeds.  This makes it easier to find where things happened in a long recording.

So that is one good method to help find a culprit, but what if you are just looking at history of root?  Can you tell me who ran what? Can you tell me when they ran the commands you see when you type ‘history’?  By default, no.  The next tidbit of info is very useful, and extremely easy to add to your machines.  Simply add the following to your /etc/profile:

export HISTTIMEFORMAT=”%d.%m.%y %T “

Yes, that is a space at the end.  If you do not put that in there you will end up with it running together with the actual command typed in history.  So your history should look like the example below:

1995 06.10.15 13:08:05 top
1996 06.10.15 13:08:05 clear
1997 06.10.15 13:08:05 df -h
1998 06.10.15 13:08:05 umount /media
1999 06.10.15 13:08:05 sudo umount /media
2000 06.10.15 13:08:05 sudo su –
2001 06.10.15 13:08:07 history

I hope this helps someone save some time, as it has me.  Please feel free to share with others.

-M