LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-08-2008, 10:35 AM   #16
ufotofu
LQ Newbie
 
Registered: Apr 2008
Posts: 7

Rep: Reputation: 0

Quote:
Originally Posted by rg3 View Post
if you use Slackware in a production server in a serious environment it would be good practice or even a requirement to install only the software you really need, specially if you expect security audits.
I administer a few servers running slackware in a small to medium-sized production environment (averaging 50-75 employees, with a network of 30-40 PCs and other devices). Services include samba, postgresql, dhcp, ntp, and of course ssh. What I do (on installation) is select only the software *sets* I need to run a GUI-less server, and then simply go ahead with "full install" mode. This allows you to have a quick, relatively minimal install, yet still keeping things simple. From a system administration perspective, simplicity is good.

I don't go through the entire list and uninstall packages I don't need. That would add time and complexity to the install project, without much gain in the end, and I'd have more config steps to keep track of. I simply disable any unnecessary services being started in /etc/rc.d and get on with it. Before deploying a new server installation, I run a "nmap -p 0-65535" to verify that only my services are running and no others.

If I was running servers exposed to the internet, or servers under very high load, I would be inclined to trim the installation down further and tweak more. But for what I'm doing, it would be overkill. The packages I don't use are doing nothing but sitting dormant on the disk.

By staying at the software sets level, I believe I have a more vanilla installation. If I was to manually trim the system down package by package, I'd have a less vanilla installation, because my configuration would be more complex. I stick with the pre-compiled (generic) kernel for the same reason. Configuration of services too - I go with the default when possible, only tweaking when there's a very good reason. All of this means that I have less ways of screwing it up.

Before my upgrade to 12.1, my previous installation (10.2) had stayed up for over a year at times.

Last edited by ufotofu; 06-08-2008 at 05:53 PM.
 
Old 06-08-2008, 11:09 AM   #17
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
Quote:
Originally Posted by glore2002
c) Removing KDE components that come with Slackware are not recommended to uninstall (I am not sure about this point but if there is a safe way to remove things -such as noAtun or JuK- please, let me know).
The KDE included with Slackware is comprised of only a few large packages, and so you cannot uninstall a single application like Noatun (though many would like to). The best you can do is disable the app, but the effort is probably not worth it, and it makes it more difficult to keep your system in a known state (more things to keep track of, basically).
Quote:
Originally Posted by glore2002
d) Some orphan files may be left behind but they are not a real problem if I leave them the way they are.
In MY opinion, this is mostly true. Although there may be some orphaned files that are larger and taking up space, the vast majority of them are likely small configuration files that are not really harming the system in any way. If you want to maintain a PERFECTLY clean system then you can deal with them, but it's not absolutely necessary for most purposes.
Quote:
Originally Posted by glore2002
e) Once I installed a package. ¿What can I remove after installing it? Can I remove the /tmp contents? (I think yes but I didn't do it yet). For instance, I download and install a package from Slackbuild.org. Once installed, what should I keep to be able to reinstall the package if needed and what can I safely remove?
You can remove everything that was created by the SlackBuild, with the exception of the .tgz package if you want to keep it for future installation (though you could probably just build it again). slackbuilds.org usually creates directories under /tmp/SBo. You can safely delete the entire /tmp/SBo directory (or whatever directory it is creating, if you customized the build location) without harm. The .tgz package is required for installation, but not uninstallation. If you think you may uninstall the app and may want to reinstall it later, then you should keep the .tgz package somewhere (unless you want to rebuild the package later); however, if you don't want to keep it around, it is not required for removal of the package. All of the files contained in the package are listed in /var/log/packages/packagename, so removepkg (or pkgtool) knows what files to remove even if the .tgz package is no longer present (as a side note, the doinst.sh script used for the package is located in /var/log/scripts, so if you're curious about what was installed by the package you should look there too).
 
Old 06-08-2008, 11:17 AM   #18
shadowsnipes
Senior Member
 
Registered: Sep 2005
Distribution: Slackware
Posts: 1,443

Rep: Reputation: 73
Quote:
Originally Posted by glore2002 View Post
First of all, thanks for such a discussion. I really appreciate it.

Let's see if I can put some thing in order to make it clearer to me:

a) I should only remove unneeded stuff if necessary (for instance if I run out of disk space).

b) Slackware is clean enough. It is not compulsory , as in Win, to clean residual files often.
As long as you don't install a bunch of files on your computer outside of packages (files under your user directory are an exception) your computer should be pretty clean. When you remove a package practically all of those files you be deleted. The ones that aren't should be listed when you removepkg. An exception to this is any files created by the doinst.sh or config files under /etc. Unless you have a reason to get rid of config files you should not do so. They take up almost no space relative to the size of the disk.

As long as you use good habits with the pkgtools your home directory should be the main place you will have to manually keep organized. Doing regularly logged backups with rsync can help you see the changes in your system (see my post above).

Quote:
Originally Posted by glore2002 View Post
c) Removing KDE components that come with Slackware are not recommended to uninstall (I am not sure about this point but if there is a safe way to remove things -such as noAtun or JuK- please, let me know).
The problem with removing a program or two from KDE is that they are packaged in bundles. You can't just remove Juk, for instance, as it is a part of the kdemultimedia package. Some distros, such as Arch Linux, use a modular KDE that allows you to remove single programs. This is not likely to happen in Slackware because it is a mess to maintain (part of the reason GNOME was removed).

If you don't need KDE or its apps you can save over 3GB by not having the KDE series installed.

Slackware Full install vs Not Full install
A full install is generally recommended unless you know what you are doing. The main reason for this is to help you avoid breaking something by not having a package your system needs. Obviously if you are short on disc space or want to minimize attack surfaces having less is more.

Quote:
Originally Posted by glore2002 View Post
d) Some orphan files may be left behind but they are not a real problem if I leave them the way they are.
Most likely they are fine as is as most will be config files under /etc. Again, pay attention to the messages when you removepkg as it will tell you, for instance, if there are any unique files under a directory created by a package. You will have to manually delete these if you don't want them.

Quote:
Originally Posted by glore2002 View Post
e) Once I installed a package. ¿What can I remove after installing it? Can I remove the /tmp contents? (I think yes but I didn't do it yet). For instance, I download and install a package from Slackbuild.org. Once installed, what should I keep to be able to reinstall the package if needed and what can I safely remove?
Slackbuilds.org does not distribute packages. It distributes scripts and associated files that let you build packages using the upstream sources. After you are done creating the package you can remove the entire /tmp/SBo directory if you want. The actual packages (they all end in SBo.tgz) will be left under /tmp unless you moved them somewhere else. I recommend saving these under your /root directory and/or on some removable media so you can reinstall you packages later (or install them on another system).

Quote:
Originally Posted by glore2002 View Post
f) What does clean cache mean in KPackage? What would I really remove if choosing this option?
Nothing for Slackware as far as I know. I think it is supposed to clear the package cache for other package management systems (APT, Yast, etc). Slackware's native package management tools don't need a cache.
 
Old 06-08-2008, 03:58 PM   #19
glore2002
Member
 
Registered: Mar 2007
Location: Buenos Aires, Argentina.
Distribution: Lubuntu 17.10 x64
Posts: 510

Original Poster
Rep: Reputation: 33
Thumbs up Great explanation!

Thanks to you all!

Great explanation. Time to put all these things into practice.

Thanks again my friends!

Glore2002.-
 
Old 06-09-2008, 05:43 AM   #20
irishbitte
Senior Member
 
Registered: Oct 2007
Location: Brighton, UK
Distribution: Ubuntu Hardy, Ubuntu Jaunty, Eeebuntu, Debian, SME-Server
Posts: 1,213
Blog Entries: 1

Rep: Reputation: 88
Hi glore,

A practical suggestion may be to try things out on an old machine, that you use specifically for that purpose. I run quite a few different distros for work and home, and I find that for machine I am using, I prefer the control and tweakability and, to use someone elses word, vanillaness(!) of slack. I enjoy playing with slack to see what a good installation of linux can look like. But i did that on an old machine at home, which was suitable for the purpose!

Best of luck with playing with slack! It's a cool distro, one of the best, once you take the time to learn it.
 
Old 06-09-2008, 10:16 AM   #21
Lufbery
Senior Member
 
Registered: Aug 2006
Location: Harrisburg, PA
Distribution: Slackware 64 14.2
Posts: 1,180
Blog Entries: 29

Rep: Reputation: 135Reputation: 135
Glore,

Very quickly, the traditional method for installing software in Linux is to download the source code, uncompress it, and then run the commands: "./configure" then "make" and then "make install" (without the quotes). Do a Google search on "./configure && make && make install" to find out more. There are other ways to compile software, but that is still seemingly the most common. This process takes the source code, which is essentially text, and converts it to machine code, which is essentially binary files run by the computer.

The result is compiled software that is installed in the (hopefully) correct spots in the file system. The problem is that there is no easy way to track which files end up at which locations. The result is that it can be extremely difficult to remove or upgrade applications. The files are in the right place, but there's no record of which files go with which program.

Package managers solve that problem. Slackware packages are simply tar archives, compressed with gzip (with the .tgz extension), that contain a file structure and the compiled files. Slackware's package tools unpack the package files to the correct directories and maintain a database tracking where the files are installed.

I use two tools to create Slackware packages for software not included in the distribution: Slackbuild scripts and a program called src2pkg. Slackbuild scripts are scripts written in the same language used by the command shell -- the program that takes your typed input and displays the computer's output. I pretty much use the scripts at www.slackbuilds.org. It's a great site and many of the people responsible for that site and the scripts on it, visit this message board.

Src2pkg is a program that will automatically compile source files and create Slackware packages for them. You can find out a lot more about src2pkg from the src2pkg wiki.

These are not the only tools, but they are the ones I use most often. In either case, I only install Slackware packages, and never simply run "./configure && make && make install" for the software I install, because I like to have the option of easily removing or upgrading packages. Following this procedure will prevent the majority of orphaned files that could occur.

To find out more about Slackware's package tools, type "info" (without the quotes) followed by "pkgtool" and "info upgradepkg", "info removepkg" and "info installpkg".

Regards,

-Drew
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Cleaning Ubuntu. Unnecesary files. glore2002 Linux - Software 2 05-08-2007 08:59 AM
Five things I still can't do with Slackware 11... Lufbery Slackware 13 11-03-2006 10:22 PM
Cleaning up my Slackware 10.1 avheretic Slackware 4 07-26-2006 04:09 AM
Cleaning up files on my Slackware box? JockVSJock Slackware 3 06-29-2005 08:29 AM
deleting things that don't exist... nakedjohn Linux - Newbie 2 07-16-2003 09:43 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:15 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration