https://www.slackwiki.com/api.php?action=feedcontributions&user=Rworkman&feedformat=atomSlackWiki - User contributions [en]2024-03-28T19:39:30ZUser contributionsMediaWiki 1.40.0https://www.slackwiki.com/index.php?title=Grub&diff=3284Grub2021-10-05T02:00:12Z<p>Rworkman: speling is dificult</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
<br />
'''installing grub on slackware'''<br />
<br />
grub-install /dev/XXX<br />
<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
after updating kernel dont forget to run<br />
<br />
grub-mkconfig -o /boot/grub/grub.cfg</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Writing_A_SlackBuild_Script&diff=3218Writing A SlackBuild Script2019-11-04T20:25:53Z<p>Rworkman: Undo revision 3211 by Captain-sensible (talk) - I'm not necessarily opposed to this text, but it needs attribution - as it was, it appeared to be written by me. -RW</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
= Introduction =<br />
<br />
Originally written by Florian Mueller jjdm@jjdm.org<br />
Substantial cleanup and enhancement by Robby Workman (rworkman)<br />
<br />
If you use slackware as your main operating system, you have probably wanted to install quite a few applications which are not available in the official slackware.com or even third-party repositories like pkgs.org, or perhaps you just don't like using third-party packages. In this situation, you have several options on how to install the application:<br />
<br />
* ./configure && make && make install<br />
* use checkinstall<br />
* use installwatch<br />
* compile and use makepkg by hand<br />
* write a SlackBuild script<br />
<br />
I will go through the last option: writing [[SlackBuild Scripts]] (which combines the best qualities of all the other aforementioned methods). With a SlackBuild script, you have the build process automated, which will allow you to easily do later upgrades or patches to the package. SlackBuild scripts are also the method by which Patrick Volkerding builds all of the official packages for Slackware. If you look at the various scripts from different sources, you will notice that there is generally an application-independent portion of a script and an application-specific portion of the script.<br />
<br />
I cannot teach you how to build the "perfect" package, as reaching that goal requires fairly in-depth knowledge of the Slackware operating system. You must consider the interactions of your proposed package with all of the other packages within the distribution; they must be integrated seamlessly. What I can teach you is how to build a package that works and which stays true to the "Slackware Way."<br />
<br />
"But it takes so much time!"<br />
<br />
It will take approximately thirty minutes to go through this tutorial and about fifteen minutes to create each package (actual compile process not included), but the time you save in the future (you want to create a newer version of the package) makes the initial time expenditure worth it.<br />
<br />
= The Slackware package structure =<br />
<br />
See [[Packages#Slackware Package Layout]]<br />
<br />
= Setting up your build environment =<br />
<br />
See [[Build_Environment]] for examples of how various users do this.<br />
<br />
= Getting Started =<br />
<br />
Hopefully, everything is now clear about Slackware package structure, and you have set up a clean build environment, so we'll begin the process of building a package with a SlackBuild script.<br />
<br />
For this example, we'll create a package of latex2html - I made my homepage with that tool.<br />
<br />
First, you have to create a directory named <build_environment>/latex2html/. Get the most recent source code release of latex2html place it in this directory. Note that use of wget below to obtain the most recent source code is optional - you can just as well use your favorite web browser to download it, and then move it into the correct directory.<br />
<br />
$ cd <build_environment><br />
$ mkdir latex2html<br />
$ cd latex2html<br />
$ wget -O latex2html-2019.2.tar.gz [https://github.com/latex2html/latex2html/archive/v2019.2.tar.gz https://github.com/latex2html/latex2html/archive/v2019.2.tar.gz] #6 th June 2019 release<br />
<br />
Next, we'll create some other needed files with touch. If you're not familiar with touch, see:<br />
man touch<br />
Note that the *.SlackBuild file will always contain the name of the application for which it's written; for example, gaim would have gaim.SlackBuild.<br />
<br />
$ touch latex2html.SlackBuild<br />
$ touch slack-desc<br />
<br />
Extract the source code of the application, because we'll need to look at the configure script later on to determine what options we need to pass to it.<br />
<br />
<br />
$ tar xvzf latex2html-2019.2.tar.gz || exit 1 <br />
<br />
x -extract<br />
v -verbose<br />
f -file <br />
z -basically ungzip<br />
<br />
= Writing the slack-desc file =<br />
<br />
See this [[Slack-desc]] page on SlackWiki.org for instructions on how to write a proper slack-desc file.<br />
<br />
= Writing the SlackBuild script =<br />
<br />
This is the section which takes the most time, and I'll go through it with you step by step. When you build more packages, you'll probably be able to just copy an existing SlackBuild script and customize it. First, you need to understand that you can write your SlackBuild script in any manner you choose so long as it creates a working package; the method described here is more or less the way Pat Volkerding [[http://slackware.com/~volkerdi]] does it, but even Pat has several different styles for writing the official SlackBuild scripts. Therefore, if you see something you would do a different way, feel free to do it that way - it's okay.<br />
<br />
===Initial Setup===<br />
<br />
Open the file latex2html.SlackBuild with your favourite editor. What follows below is a piece by piece walk-through of a working SlackBuild script. You may certainly paste the exact contents of those pieces, but in the author's opinion, you have a better chance of understanding it if you write everything yourself.<br />
<br />
First, you'll need to set your shell interpreter. This should be /bin/sh, as *every* Slackware system is guaranteed to have this shell installed, and you want maximum portability. For this same reason, be careful not to use any extensions and/or syntax that is customized for your particular shell (bash, zsh, or whatever), as it won't be interpreted correctly. The '-e' flag tells the shell to exit on any error; this helps with both debugging your script as well as ensuring your script does not proceed in an unknown state.<br />
<br />
#!/bin/sh -e<br />
<br />
You might want to include a license of some sort with your SlackBuild script (preferably a GPL or BSD-style license.For the sake of brevity an example has been put on discussion page ), but at a minimum, you'll want something like this:<br />
<br />
#<your name> revision date yyyy/mm/dd<br />
<br />
With the next few lines, we set some variables that will be used throughout the script. First is the "CWD" variable; in our case, CWD will be <build_environment>/latex2html/. We also test if the TMP variable is set, and if not, we set it to /tmp.<br />
<br />
#Set initial variables: <br />
<br />
CWD=$(pwd)<br />
if [ "$TMP" = "" ]; then<br />
TMP=/tmp<br />
fi<br />
<br />
Some people like to build in a subdirectory of /tmp (such as /tmp/build), but that's up to you.<br />
<br />
# The version which appears in the application's filename<br />
VERSION=${VERSION:-2019.2}<br />
<br />
# If the version conflicts with the Slackware package standard<br />
# The dash character ("-") is not allowed in the VERSION string<br />
# You can set the PKG_VERSION to something else than VERSION<br />
PKG_VERSION=2002.2.1 # the version which appears in the package name. <br />
<br />
<br />
# Automatically determine the architecture we're building on:<br />
if [ -z "$ARCH" ]; then<br />
case "$( uname -m )" in<br />
i?86) ARCH=i486 ;;<br />
arm*) ARCH=arm ;;<br />
# Unless $ARCH is already set, use uname -m for all other archs:<br />
*) ARCH=$( uname -m ) ;;<br />
esac<br />
fi<br />
<br />
<br />
<br />
<br />
<br />
# First digit is the build number, which specifies how many times it has been built. <br />
# Second string is the short form of the authors name, typical three initials:w<br />
BUILD=${BUILD:-1_rlw}<br />
<br />
# The application's name<br />
APP=latex2html<br />
<br />
# The installation directory of the package (where its actual directory<br />
# structure will be created) <br />
PKG=$TMP/package-$APP<br />
<br />
Set SLKCFLAGS (which will be used for both CFLAGS and CXXFLAGS). If you are building on a system with an earlier version of gcc than 3.4.x, then you'll need to use "-mcpu" instead of "-mtune" below.<br />
<br />
if [ "$ARCH" = "i486" ]; then<br />
SLKCFLAGS="-O2 -march=i486 -mtune=i686"<br />
LIBDIRSUFFIX=""<br />
elif [ "$ARCH" = "i686" ]; then<br />
SLKCFLAGS="-O2 -march=i686 -mtune=i686"<br />
LIBDIRSUFFIX=""<br />
elif [ "$ARCH" = "x86_64" ]; then<br />
SLKCFLAGS="-O2 -fPIC"<br />
LIBDIRSUFFIX="64"<br />
else<br />
SLKCFLAGS="-O2"<br />
LIBDIRSUFFIX=""<br />
fi<br />
<br />
<br />
<br />
<br />
<br />
The section just finished sets up a few application-specific variables. When you want to create a package of some other application, you can usually just change the variables, and most of the further steps will work automatically.<br />
<br />
=== Extract Sources ===<br />
<br />
# Delete the leftover directories if they exist (due to a previous build)<br />
# and (re)create the packaging directory<br />
rm -rf $PKG <br />
mkdir -p $TMP $PKG<br />
rm -rf $TMP/$APP-$VERSION<br />
<br />
# Change to the TMP directory<br />
cd $TMP || exit 1<br />
<br />
# Extract the application source in TMP<br />
# Note: if your application comes as a tar.bz2, you need tar -jxvf<br />
tar -zxvf $CWD/$APP-$VERSION.tar.gz || exit 1<br />
<br />
# Change to the application source directory<br />
cd $APP-$VERSION || exit 1<br />
<br />
# Change ownership and permissions if necessary<br />
# This may not be needed in some source tarballs, but it never hurts<br />
chown -R root:root .<br />
chmod -R u+w,go+r-w,a-s .<br />
<br />
===Configure and Compile Sources===<br />
<br />
# Set configure options<br />
# If your app is written in C++, you'll also need to add a line for CXXFLAGS<br />
CFLAGS="$SLKCFLAGS" \<br />
./configure \<br />
--prefix=/usr \<br />
--sysconfdir=/etc \<br />
--localstatedir=/var \<br />
--with-perl=/usr/bin/perl \<br />
--enable-eps \<br />
--enable-gif \<br />
--enable-png \<br />
--build=$ARCH-slackware-linux \<br />
--host=$ARCH-slackware-linux <br />
<br />
# compile the source, but exit if anything goes wrong<br />
make || exit<br />
<br />
# Install everything into the package directory, but exit if anything goes wrong<br />
make install DESTDIR=$PKG || exit<br />
<br />
There are three configure options I always set:<br />
<br />
* --prefix=/usr<br />
* --sysconfdir=/etc<br />
* --localstatedir=/var<br />
<br />
This makes configuration files go to /etc, state files (such as log files) go to /var, and the rest goes to /usr. That's the usual Slackware way, but it's your system, so you can certainly install everything in /usr/local or some other location. See the Unix Filesystem Hierarchy Standard [[http://www.pathname.com/fhs/]] for more information on "correct" locations of various filetypes.<br />
<br />
You notice that there were several other options passed to the configure script, and for each application you compile, you have to figure those out for yourself - that's why you were told to extract the sources earlier in this process. You simply cd into the source directory and run:<br />
./configure --help<br />
This will produce a page or two (sometimes more, though) of information about various options that are specific to the application. Read through this information and figure out what you need (I like to pipe that command through lpr to get a printed copy, but you can certainly use some sort of pager as well:<br />
./configure --help | lpr<br />
./configure --help | less<br />
<br />
The DESTDIR variable is very important in this script because it specifies the directory in which the files should be installed. This should always be our package directory ($PKG). Unfortunately, some applications' Makefiles will not support the DESTDIR variable, so you can't use it for those apps. A simple line like this:<br />
grep DESTDIR Makefile*<br />
while inside the source directory should tell you whether it supports DESTDIR or not. If you get some lines of output with $DESTDIR in them, you're in good shape. If the command returns no output, then the Makefile does not support the DESTDIR variable.<br />
<br />
Here's a piece of advice: ALWAYS go through the ./configure && make && make install DESTDIR=/somedir process manually and as a NORMAL USER account BEFORE you run your SlackBuild script. There are quite a few applications out there which try to do "funny stuff" during the installation phase.<br />
For example, apcupsd will attempt to patch your /etc/rc.d/rc.6 init script<br />
Yes, it's possible to avoid this with a configure option, but it's not obvious that you would need<br />
to do so until you look at all of the Makefiles for apcupsd (or watch the install process)<br />
Anyway, if you go through the process as a normal user, you will get "Permission Denied" errors and such if the install process tries to write anywhere it's not allowed to do so.<br />
<br />
=== Install Documentation ===<br />
<br />
# Create a directory for documentation<br />
mkdir -p $PKG/usr/doc/$APP-$VERSION<br />
<br />
# Copy documentation to the docs directory and fix permissions<br />
cp -a BUGS Changes FAQ INSTALL LICENSE MANIFEST README TODO docs/ $PKG/usr/doc/$APP-$VERSION<br />
find $PKG/usr/doc/$APP-$VERSION -type f -exec chmod 644 {} \;<br />
<br />
I (rworkman) also like to place a copy of my SlackBuild script in this directory<br />
cat $CWD/$APP.SlackBuild > $PKG/usr/doc/$APP-$VERSION/$APP.SlackBuild<br />
<br />
Make sure you look inside the actual source archive of the application, because some applications won't have all of the documentation files specified above, and some applications will have additional files. In other words, don't just copy/paste what you see above into your SlackBuild script - you *must* customize this section for each individual application.<br />
<br />
=== Final Touches ===<br />
<br />
# Create the ./install directory and copy the slack-desc into it<br />
mkdir -p $PKG/install<br />
cat $CWD/slack-desc > $PKG/install/slack-desc<br />
<br />
NOTE: In some cases, you will have some sort of command or setup that<br />
needs to run after the package contents are installed - for this, you<br />
would add a file to $CWD called "doinst.sh" which contains the needed<br />
commands, and then compress that file with gzip. The SlackBuild script<br />
will zcat (which means to gunzip and cat its contents) that file and <br />
write the output to a doinst.sh file in the $PKG/install directory.<br />
<br />
# Add doinst.sh to package (if it exists)<br />
if [ -e $CWD/doinst.sh.gz ]; then<br />
zcat $CWD/doinst.sh.gz > $PKG/install/doinst.sh<br />
fi<br />
<br />
Let's conserve space if we can; strip libraries and binaries and compress man pages with gzip<br />
Note that you might be able to use "make install-strip" instead of "make install" above instead to accomplish the same purpose<br />
<br />
# Strip some libraries and binaries<br />
( cd $PKG<br />
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null<br />
)<br />
<br />
# Compress man pages if they exist<br />
if [ -d $PKG/usr/man ]; then<br />
( cd $PKG/usr/man<br />
find . -type f -exec gzip -9 {} \;<br />
for i in $(find . -type l) ; do ln -s $(readlink $i).gz $i.gz ; rm $i ; done<br />
) <br />
fi<br />
<br />
# Compress info pages if they exist (and remove the dir file)<br />
if [ -d $PKG/usr/info ]; then<br />
gzip -9 $PKG/usr/info/*.info<br />
rm -f $PKG/usr/info/dir<br />
fi<br />
<br />
=== Build the Package ===<br />
<br />
# Build the package<br />
cd $PKG<br />
/sbin/makepkg -l y -c n $TMP/$APP-$PKG_VERSION-$ARCH-$BUILD.tgz<br />
<br />
= Other Concerns =<br />
<br />
=== DESTDIR Option Not Available ===<br />
<br />
As mentioned above, there are quite a few applications whose Makefiles do not support the DESTDIR option for make install. On some applications the DESTDIR Makefile variable has another name. For example, some Qt applications use the variable INSTALL_ROOT for the same purpose. If you can understand Makefiles, it is probably worth your time to take a look at its contents and try to find out which actions are performed in the install rule. Sometimes there will be no DESTDIR equivalent at all. The <strong>best</strong> thing you can do in this situation is write a patch for the Makefile.in or equivalent, and submit it to the developer(s) for inclusion in the source, but I realize that everyone doesn't have the ability to do that. The second best thing you can do it write to the developer(s) and ask them to include that functionality in future releases. In the meantime, here are some thoughts on the subject...<br />
<br />
==== Example 1: ====<br />
Configure the build with:<br />
./configure --prefix=$PKG/usr<br />
along with your other configure options. This will install *all* of the package contents in that directory. If the package creates $PKG/usr/etc and $PKG/usr/var directories (or any other directories that should be elsewhere), you can probably just move them to their correct location within the package directory tree and everything will be fine. You might also try this along with your other configure options.<br />
./configure --prefix=$PKG/usr \<br />
--sysconfdir=$PKG/etc \<br />
--localstatedir=$PKG/var <br />
There are some applications, however, which "hard-code" configuration files based on configure/Makefile parameters. In those cases, you'll have to figure out a way to patch the config file prior to packaging it, or in worst-case scenario, include instructions for the end user on how to make the necessary changes.<br />
<br />
==== Example 2: ====<br />
This example makes use of the ability to override any Makefile variable, which is called a '''macro''' in the Makefile terminology, on the command line and not have to worry about patching the Makefile to include a '''DESTDIR''' macro in the Makefile. This approach makes it a bit easier for those not familiar with Makefiles.<br />
<br />
If the Makefile does not honor '''DESTDIR''' for the 'make install' command, you can change the prefix macro, instead:<br />
make prefix=$PKG/usr install<br />
This will override the $(prefix) variable inside the Makefile and install to the location you supplied on the command line. Therefore, you can configure with the standard ''./configure --prefix=/usr'' (or ''./configure --prefix=/usr/local'') syntax, yet install to a different location as if you supplied a ''DESTDIR=$PKG/usr'' for the 'make install' command.<br />
<br />
IMPORTANT NOTE: Macro names are case-sensitive (at least for GNU make). Some Makefiles may use a "'''PREFIX ='''" macro instead of the usual "'''prefix ='''", so the 'make install' command would look like this:<br />
make PREFIX=$PKG/usr install<br />
Therefore, it's necessary to look inside the Makefile to be sure which form was used for the prefix. For large, complex makefiles, the easiest way is to 'grep' the Makefile, like so:<br />
grep -i '^prefix \?=' Makefile{,.in}<br />
The ''-i'' option makes the search case-insensitive and the ''{,.in}'' part at the end will search "Makefile" or "Makefile.in" files, the second one being a template for the "configure" script. Grep's search term is a basic regular expression, so the escaped question mark after the space (\?) means there may or may not be a space in between when searching.<br />
<br />
Once in a while, there may be a "'''PREFIX ='''" in a Makefile that is not defined which you are to edit and supply the location. Use the usual ''/usr'' (or ''/usr/local''), in this case, and then use 'make PREFIX=$PKG/usr install' to install to the package's build location.<br />
<br />
=== Patching the Sources ===<br />
<br />
Sooner or later, there will be some reason to patch the source code prior to building a package, and you'll want to be able to do this automatically. <br />
<br />
===== Obtaining the Patch =====<br />
<br />
In most cases, the patch will be provided by the author of the source code, so we're not going to discuss patch *creation* here. Download the patch and place it in the same directory as the SlackBuild script, slack-desc file, and other related files (in $CWD from above).<br />
$ wget http://someapplication.org/files/patches/bigsecuritypatch.diff<br />
It's not necessary to do the next step, but because developers generally want to conserve space if possible, it's conventional to do this:<br />
$ gzip -9 bigsecuritypatch.diff<br />
This will result in a new file called bigsecuritypatch.diff.gz -- we'll use that in the SlackBuild script in just a moment.<br />
<br />
===== Applying the Patch =====<br />
<br />
You will now need to edit your <application>.SlackBuild script so that it applies the patch before it runs configure, make, and make install. To do this, you'll want something like this to run before the configure script, but after extracting the sources:<br />
zcat $CWD/bigsecuritypatch.diff.gz | patch -p1 || exit<br />
Depending on how the patch was created, you might use a different patchlevel on that line, as in:<br />
zcat $CWD/bigsecuritypatch.diff.gz | patch -p0 || exit<br />
It's a bit beyond the scope of this HOWTO, but essentially, the -p# specifies the number of trailing directories to skip when looking for the file to patch. You'll often need to skip the top-level directory, but not always (hence the -p0).<br />
<br />
= See Also =<br />
<br />
* [[SlackBuild_Scripts]]<br />
* [[Different_Approach_To_Buildscripts]]<br />
* [[Building_A_Package]]<br />
* [[Slack-desc]]<br />
* [[Checkinstall]]<br />
* [[Compiling]]<br />
<br />
= SlackBuild Script Repositories =<br />
<br />
;* http://slackbuilds.org<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
;* http://slackbuilds.slackadelic.com/<br />
;* http://slackbuilds.rlworkman.net/<br />
;*https://slackbuilds.org/repository/14.2/academic/latex2html/?search=latex2html<br />
<br />
the last link is intended for noobs reading this document and wanting to download a working slackbuild for latex2html which was based on this tutorial. Its been tested on current stable Slackware 14.2 32 bit</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Life_of_a_Software_Package&diff=3161Life of a Software Package2018-03-11T17:29:18Z<p>Rworkman: Reverted edits by Jhonthomas (talk) to last revision by Grissiom</p>
<hr />
<div>From the programmer's keyboard to your (Slackware) Linux system.<br />
<br />
= Introduction =<br />
<br />
This article explains how a program someone writes in one side of the world ends up being managed in your system. It's meant to be easy to understand for a novice user coming from Windows, and only requires some basic knowledge of Unix systems. Specifically, the reader should know:<br />
<br />
* How basic Unix permissions work.<br />
* How to interpret the basic output of the ''ls'' command.<br />
* How a command line interface works.<br />
<br />
It only contains general ideas that could help a novice user understand the existing differences when installing software under Windows and under Unix, but no specific information about how to do it. The distribution manual will give you the specific details you need, and may be a good read after you have read this article.<br />
<br />
= From source code to machine language =<br />
<br />
'''Note''': You do not need to run any of the commands in this section. It's enough to understand the text and part of the output.<br />
<br />
When a programmer creates a program, it's very common to write the program in a so-called high level language. In other words, he doesn't create the program executable directly specifying the intructions for the computer to run. He writes the program in a language that allows him to represent the program structure and logic, and then that logic is translated to a language the bare machine can understand. Let's suppose someone wants to write a ''Hello, World'' program in the C programming language. This is a program that prints a message to the screen and finishes, in order to check your system can translate the language you have used to machine language and to test the basic stuff works, as well as to give the novice programmer an idea on how the high level language works. This would be a very simple ''Hello, World'' program written in C:<br />
<br />
#include <stdio.h><br />
<br />
int main()<br />
{<br />
printf("Hello, World!\n");<br />
return 0;<br />
}<br />
<br />
You do not need to understand that program. The above text is what is commonly known as the '''source code''' of the program. The source code of a program in C is usually spread over one or more source files, so this program could very well be stored in a plain text file called ''hello.c''. You could view this file using a plain text editor like the Windows notepad.<br />
<br />
This file cannot be executed directly because it's not a real program. First off, it doesn't have execution permissions, and if we tried to give it execution permissions and run it, we would get an error message:<br />
<br />
$ ls -l hello.c<br />
-rw------- 1 rg3 users 74 2007-10-15 19:27 hello.c<br />
$ chmod +x hello.c<br />
$ ./hello.c<br />
./hello.c: line 3: syntax error near unexpected token `('<br />
./hello.c: line 3: `int main()'<br />
<br />
We need to use a program called ''compiler'' to get a binary and executable file. A file in a specific format that the operating system (Linux in our case) can understand. When you run it, the operating system reads the file, copies the different program components to the computer's memory and starts the program execution. If our machine has everything ready to compile C programs and we want to use the GNU C Compiler (''gcc''), we could do something as simple as:<br />
<br />
$ gcc -o hello hello.c<br />
<br />
And we would get a file named ''hello'' which is our program ready to be run. As you see, our program is simply called ''hello'' and not ''hello.exe'', which would be a common name if we were working under Windows. In Unix systems, the convention is that programs do not have any file extension in their name (like EXE). We could then run the program and see that it does what we wanted.<br />
<br />
$ ./hello<br />
Hello, World!<br />
$<br />
<br />
= Complex programs use libraries =<br />
<br />
Most programs do a more sophisticated task than printing a message on the screen and finishing. The source code of the program above has 7 lines. It is not uncommon for a simple program to have thousands of lines, and there are a good amount of complex programs out there that have millions of lines of source code. It is also a very common practice to use items called '''libraries''' (usually '''shared''' libraries) to build your program. Libraries are files that contain the machine code to perform several different tasks. For example, let's suppose you were going to create a program that needs to download some data from the Internet, via HTTP (the web) or via FTP or another network service. And also let's suppose you don't have much knowledge on how to create a program that talks to others using the network, or that the focus of your program is on solving some other problem and you don't want to lose time or create a lot of code just because you want it to be able to download a file. Fortunately for you, there is a library called ''libcurl'' that makes retrieving files over the network very easy. The library contains all the code you need, so the source code you are going to create will not contain anything specific to be able to use the network. You simply indicate that you want to use ''libcurl'' and call the library functions everytime you want to download a file. Do you need to learn to sail or fly a plane or a different language if you want to send a letter to a friend in a different continent? No, you put the letter in the mailbox and the postal service does it for you. Libraries work like this.<br />
<br />
In the moment you decide to do this, your program starts '''depending''' on ''libcurl''. Some pieces of the library need to be present in your system if you want to compile that program to create an executable, and some other pieces need to be present in the moment you want to ''run'' the program. Else, the program will not compile or will not be able to run. Libraries are convenient because, if managed well, you can install them in your system once and they will be used by every program that needs them. This is why libraries are regarded as a ''good thing'' or a ''good idea'' in the programming world, in most cases.<br />
<br />
In Windows, shared libraries are called DLLs, as the library files usually have the DLL extension. In Unix, it's common for them to have the ''.so'' suffix, or some other containing it. For example, I have ''libcurl'' in my system, and the shared library is located in the file ''/usr/lib/libcurl.so.4.0.0''.<br />
<br />
= Libraries and programs all over the place need a package manager =<br />
<br />
So your system is going to be populated by a lot of programs, many of them using many different libraries for different tasks, some of them having some libraries in common, others having nothing in common. As you can guess, this situation can evolve into a pretty chaotic system. Let's describe how Windows did this in the past, and how Unix systems have been trying to handle the situation for a good amount of years now.<br />
<br />
In Windows, most people distribute programs already compiled. You get a group of files or a single file that holds your program already prepared to be run. You extract those contents and place them somewhere in your hard drive, usually all of them under a specific directory (folder). You could then create some shortcuts in the ''start'' menu and the program is ready to be run. A installer program usually does all of this for you, asking some questions. What happens when the program uses a library? If the library is not very common and cannot be assumed to exist in a standard Windows installation, the common practice is to include a copy of the library with the program. If it's a relatively uncommon library, the installer usually puts it in the same place as the program, and when it is run and requests the library, the system first looks in the folder holding the program and finds the library there, and starts to use it. If it's not an uncommon library but you need a specific version of it, the installer may try to install it in a common place so all the programs can use it. It was very typical, when you had a system in which you had installed a lot of software as time passed, that the installer would ask you "I am trying to install the following library, but it appears to be present in your system in a newer version. Do you want me to replace the copy of it with my copy or do I leave it as it is?". And, in the same line, when you removed the program it would say "I was going to remove this library from the common place, but other programs may want to use it. Can I remove it or should I keep it there?". This chaos was called "DLL Hell".<br />
<br />
Unix tries to avoid this problem in several ways, and its solutions bring the need of a package manager as we will explain. First off, in Unix the files on your hard drive are not grouped by program, but by their function. All binaries are stored in two or three folders, and the same for libraries or help documents. If all the documentation and help for the different programs is installed in a common location, it's easier to create a help system from which you can browse the documentation of every program installed on the computer, for example. This is generally considered a good idea and it's the tradition, but of course the idea has its detractors. Anyway, a second difference is that in Unix programs are distributed alone. If a program needs a library to be run, it needs to specify that somewhere, but only under special circumstances it's recommended to include the library as part of the program. In most cases, the library is distributed apart. Those two differences avoid the DLL hell. By installing libraries, programs, documentation and other data to common system locations, you avoid duplicating data. If there's a security problem using a library and every program using it could become compromised and make the system vulnerable, you update the library once and all the programs that use it are automatically protected, as each program doesn't include its own copy in its directory. By separating the programs from the libraries they use and distributing them apart, you make sure programs do not overwrite the libraries used by others or remove common libraries when they are removed.<br />
<br />
However, the solution itself brings some new problems. For example, if a program installs files all over common system directories and I later want to remove it, how do I know which files need to be removed? And if a program requires a library to run, can I or should I specify that fact somewhere? Package managers are the answer. Under Unix, software is many times distributed as '''packages'''. Packages are groups of files that contain programs, libraries, documentation or simply data. Under Windows, to install a program many times you download an installer file, run it and the program is installed. This installer file that holds inside all the files the program needs and extracts them to the proper location could be considered a form of package, so you get an idea. Packages in Unix are usually managed by a package manager. A package manager is a program that allows you to install packages, check the list of installed packages, remove packages and many more complex tasks depending on how powerful and featureful the package manager itself is.<br />
<br />
When you install a program using a package, the package holds the program binary, the program data and the program documentation, typically, along with information on where those files should be installed in the system, all over the place. Fortunately, prior, during or after the installation, after copying the files to your system, the package manager records somewhere the name and version of the package and the files it installed. This is the trick that allows you to later remove the package using the package manager without having to remember which files had been installed where. In addition, the package may hold information about other packages it needs installed for it to run, and this information may be used by the package manager to automatically download and install them too. Hopefully, you now start to understand the practical vision behind packages and package managers.<br />
<br />
= Too many package managers =<br />
<br />
The problem with package managers is that many Unix systems and even many different Linux distributions use many different package managers. Each one uses different package formats that cannot understand each other. Slackware uses ''pkgtools'', Debian and Ubuntu use ''apt-get'', Red Hat uses ''yum'', Mandriva uses ''urpmi'', Arch uses ''pacman'', etc.<br />
<br />
You are a programmer and created the ''Hello, World'' program we saw at the beginning. How do you distribute your program? You have several solutions. If you don't want people to get the source code of your program, you need to distribute the program already compiled and probably packaged. To do that, you could provide your own program to install and uninstall the package cleanly from any system, and distribute it somehow and break some rules to achieve maximum compatibility, so the program will run on many different systems and distributions. Many commercial games are shipped this way. Unreal Tournament 2004 for Linux is distributed this way, for example. You could also provide it as a package for each of a subset of supported systems. Many companies do this. They give you Debian, Red Hat, Suse and Mandriva packages for you to choose, for example, each in the proper format to be used with the package manager from that distribution. If you want to use the software under other system you are out of luck. You can try some tricks but it's not guaranteed to work.<br />
<br />
If, on the other hand, your program is open source and you don't mind people reading the source code of your program, the common case is to avoid creating a package for anything. You simply distribute a tarball (similar to a ZIP or RAR file) containing the source code and instructions to compile it. If someone wants a Debian package to install it, someone will have to compile your program under Debian, and make a package with the result. This is a very very very common case. In fact, distributions like Ubuntu or Debian heavily rely on '''package repositories''', network locations from where you can download thousands of packages for your system, created by a myriad of official and unofficial packagers (people that create packages for the system). For example, if you want to install a program under Ubuntu, it's very infrequent for the program not to exist already packaged in a repository, and you can download and install it, together with its dependencies, in a couple of mouse clicks.<br />
<br />
= Summing up =<br />
<br />
* Many times the programmer creates programs using source code that must be compiled.<br />
* They use libraries to make writing programs easy.<br />
* Distributing the resulting program is easier using a package manager.<br />
* Many programmers only give you the source code due to the diversity of package managers and systems.<br />
* Someone else is responsible for creating a package for a specific system.<br />
<br />
= Slackware specifics =<br />
<br />
Slackware is, as you may know, a very simple system. Being simple doesn't mean it's simple to use. On the contrary, a system with a simple design and simple tools usually requires the user to do more things to achieve a goal. The advantage of a simple design is that it's easier to understand if you want to know how your system works, and sometimes it's also more stable and has less bugs. As part of its simple design, the package manager in Slackware is also very simple, and its packages are also very simple. Slackware packages are tarballs (again, something like ZIP files) that, if extracted in the right place, will populate the system with the package files, and it also holds some special files with information about the package itself. As they are simple tarballs, Slackware doesn't try to hide this fact, and Slackware packages have the ''tgz/txz'' extension (short for ''tar.gz/tar.xz''), contrary to other systems in which packages have a special extension to make it clear that they are packages, like ''rpm'' or ''deb''.<br />
<br />
This is not a problem, but sometimes this confuses novice users. They go to the program webpage and download the program source code in a tarball (usually a file with ''tar.gz'' extension) and think "Hey, if Slackware packages are tarballs and this is a tarball, I'm going to install this file with the package manager". Wrong! Even when the package manager complains that the package name does not end in ''tgz'' but on ''tar.gz'', they many times rename the file and try again. Those are two mistakes in a row. The package manager will try to extact the tarball contents to that special location we mentioned earlier and nothing will happen, as the files inside the tarball are not structured as they need to be, but this is the small problem. The big one is that what you are trying to install is the source code of the program, and not the program itself! Remember, you need to compile it first in the majority of cases.<br />
<br />
Under Slackware, you should first check if there is an official package for the program. If there is not, you could try to to download a ready to use package from a place or someone you trust. Else, you could compile the program yourself and create a package for it, and then install the package. The compilation and package creation can be automated sometimes for ease of use, for example using [[SlackBuild Scripts|SlackBuild scripts]].<br />
<br />
[[Category:Information]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Bluetooth&diff=982Bluetooth2015-11-25T04:20:11Z<p>Rworkman: Add note re adding nonfree firmware</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
== Introduction ==<br />
This tutorial is meant to simplify the process of configuring a GNU/Linux Distribution, specifically Slackware, to use Bluetooth wireless technology. I will show you step by step how I setup my system and got Bluetooth functioning. Since it is unlikely that you have the exact same hardware that I do, you may need to modify a few steps to fit your needs.<br />
<br />
== Example System Information ==<br />
This is a list of my specific hardware that applies to this topic. Do not worry if your's is not exactly the same because you can still use this information to guide you through the process.<br />
<br />
;Motherboard (USB Ports)<br />
:[http://www.msicomputer.com/product/p_spec.asp?model=K8N_Neo4_Platinum/SLI MSI Neo4 Platinum/SLI]<br />
;Bluetooth USB Dongle<br />
:[http://www.amazon.com/gp/product/B0001Q5SZ0/103-7636612-6018206?v=glance&n=172282 Kensington Bluetooth USB Adapter (33085)]<br />
;Cell Phone<br />
:[http://www.motorola.com/motoinfo/product/details.jsp?globalObjectId=72 Motorola V551]<br />
;[http://www.slackware.org Slackware-Current (as of 5/31/06)]<br />
;[http://www.kernel.org Kernel 2.6.16.16] (worked on 2.6.15.6 also)<br />
<br />
== Kernel Configuration ==<br />
The first step is enabling the drivers for USB and Bluetooth in your kernel. I'm not sure exactly which kernel version began including Bluez Bluetooth drivers, but my 2.6.15.6 kernel had them. [http://www.westmaster.com/zidek/p900/bluetooth/ From this page], it looks like 2.6.5 did not have Bluetooth drivers and needed to be patched. If you are running an older kernel, follow the directions on that page to apply the Bluez patch. If you are unfamiliar with the kernel configuration/compilation sequence, then check out the [[Kernel26Compilation]] tutorial before proceeding.<br />
<br />
=== USB support ===<br />
For the less-advanced user (like myself), it is safe to go through and answer `M` to everything that you can, and `Y` to everything that can not take `M`. You should not enable any of the "debug" options, I'm not 100% sure why, but I'm pretty sure that these options will give you verbose output that is only needed for kernel hackers. Below, you can see the options I have set in my .config file for my kernel. The options listed are just those that I thought pertained to getting my USB ports working and able to recognize my USB dongle.<br />
#<br />
# USB support<br />
#<br />
CONFIG_USB_ARCH_HAS_HCD=y<br />
CONFIG_USB_ARCH_HAS_OHCI=y<br />
CONFIG_USB=y<br />
# CONFIG_USB_DEBUG is not set<br />
#<br />
# Miscellaneous USB options<br />
#<br />
CONFIG_USB_DEVICEFS=y<br />
CONFIG_USB_BANDWIDTH=y<br />
# CONFIG_USB_DYNAMIC_MINORS is not set<br />
# CONFIG_USB_SUSPEND is not set<br />
# CONFIG_USB_OTG is not set<br />
#<br />
# USB Host Controller Drivers<br />
#<br />
CONFIG_USB_EHCI_HCD=m<br />
CONFIG_USB_EHCI_SPLIT_ISO=y<br />
CONFIG_USB_EHCI_ROOT_HUB_TT=y<br />
CONFIG_USB_ISP116X_HCD=m<br />
CONFIG_USB_OHCI_HCD=y<br />
# CONFIG_USB_OHCI_BIG_ENDIAN is not set<br />
CONFIG_USB_OHCI_LITTLE_ENDIAN=y<br />
CONFIG_USB_UHCI_HCD=y<br />
CONFIG_USB_SL811_HCD=m<br />
<br />
=== Bluetooth support ===<br />
Again, it is safe to enable everything that says "Bluetooth" as a Module. Below are the options from my .config file that I thought might be relevant.<br />
#<br />
# FIR device drivers<br />
#<br />
CONFIG_USB_IRDA=m<br />
CONFIG_SIGMATEL_FIR=m<br />
CONFIG_NSC_FIR=m<br />
CONFIG_WINBOND_FIR=m<br />
CONFIG_TOSHIBA_FIR=m<br />
CONFIG_SMC_IRCC_FIR=m<br />
CONFIG_ALI_FIR=m<br />
CONFIG_VLSI_FIR=m<br />
CONFIG_VIA_FIR=m<br />
CONFIG_BT=m<br />
CONFIG_BT_L2CAP=m<br />
CONFIG_BT_SCO=m<br />
CONFIG_BT_RFCOMM=m<br />
CONFIG_BT_RFCOMM_TTY=y<br />
CONFIG_BT_BNEP=m<br />
CONFIG_BT_BNEP_MC_FILTER=y<br />
CONFIG_BT_BNEP_PROTO_FILTER=y<br />
CONFIG_BT_HIDP=m<br />
#<br />
# Bluetooth device drivers<br />
#<br />
CONFIG_BT_HCIUSB=m<br />
CONFIG_BT_HCIUSB_SCO=y<br />
CONFIG_BT_HCIUART=m<br />
CONFIG_BT_HCIUART_H4=y<br />
CONFIG_BT_HCIUART_BCSP=y<br />
CONFIG_BT_HCIBCM203X=m<br />
CONFIG_BT_HCIBPA10X=m<br />
CONFIG_BT_HCIBFUSB=m<br />
CONFIG_BT_HCIVHCI=m<br />
CONFIG_IEEE80211=m<br />
# CONFIG_IEEE80211_DEBUG is not set<br />
CONFIG_IEEE80211_CRYPT_WEP=m<br />
CONFIG_IEEE80211_CRYPT_CCMP=m<br />
CONFIG_IEEE80211_CRYPT_TKIP=m<br />
<br />
Now, just compile the kernel and reboot in to it.<br />
<br />
== Userland ==<br />
At a bare minimum, you need to install bluez-libs and bluez-utils from http://www.bluez.org. I used the binary package provided by [http://www.develia.org/tarballs.php?p=networking develia.org], but that was before I knew about SlackBuild scripts. If you can not find a SlackBuild script and you do not want to create your own, you should use [[Checkinstall]] at the very least.<br />
<br />
At this time, you might as well install KDE-Bluetooth, also. I think I grabbed my binary package from [http://www.linuxpackages.net LinuxPackages], but that was also before I knew better. You can either grab the source code on it's own from [http://sourceforge.net/project/showfiles.php?group_id=89888 SoureForge] or as a part of [ftp://ftp.kde.org/pub/kde/snapshots/kdeextragear-multimedia.tar.bz2 KDE Extra Gear]. Again, use a Slackbuild script or [[Checkinstall]] to install these.<br />
<br />
For more information on SlackBuild scripts, you can see the following tutorials: [[SlackBuild Scripts]], [[Writing A SlackBuild_ Script]], [[Slack-desc]], [[Different Approach To Buildscripts]], [[Checkinstall]]<br />
<br />
If you happen to discover that your bluetooth chip is a Broadcom that requires nonredistributable firmware (which necessarily isn't in Slackware), then see [[Btfirmware-nonfree]]<br />
<br />
== Configuration ==<br />
Now, should have all of the tools you need to start connecting your computer to your bluetooth devices. First, check the status of the bluetooth dongle with hciconfig.<br />
# hciconfig<br />
hci0: Type: USB<br />
BD Address: 00:11:22:33:44:55 ACL MTU: 377:10 SCO MTU: 16:0<br />
UP RUNNING PSCAN ISCAN <br />
RX bytes:385 acl:0 sco:0 events:18 errors:0<br />
TX bytes:322 acl:0 sco:0 commands:18 errors:0<br />
If yours says "UP RUNNING" then you are good to go. If not, you need to bring the interface up.<br />
# hciconfig hci0 up<br />
# hciconfig hci0<br />
hci0: Type: USB<br />
BD Address: 00:11:22:33:44:55 ACL MTU: 377:10 SCO MTU: 16:0<br />
UP RUNNING PSCAN ISCAN <br />
RX bytes:385 acl:0 sco:0 events:18 errors:0<br />
TX bytes:322 acl:0 sco:0 commands:18 errors:0<br />
Since the dongle works, it's time to configure the programs that will make the actual connections. Use your favorite text editor to edit the PIN in /etc/bluetooth/pin:<br />
# gvim /etc/bluetooth/pin<br />
The PIN needs to be all digits. I'm not sure if it needs to be exactly four (4) digits, but four (4) works well. Here is an example:<br />
PIN:1234<br />
Then you need to edit /etc/bluetooth/hcid.conf<br />
#<br />
# HCI daemon configuration file.<br />
#<br />
# HCId options<br />
options {<br />
autoinit yes;<br />
#security auto;<br />
security user;<br />
pairing multi;<br />
pin_helper /opt/kde/lib/kdebluetooth/kbluepin;<br />
#pin_helper /usr/bin/bluepin;<br />
#pin_helper /usr/bin/pin;<br />
#dbus_pin_helper;<br />
}<br />
device {<br />
name "BlueZ %h (%d)";<br />
class 0x3e0100;<br />
#pkt_type DH1,DM1,HV1;<br />
iscan enable; pscan enable;<br />
lm accept;<br />
lp rswitch,hold,sniff,park;<br />
# Authentication and Encryption (Security Mode 3)<br />
#auth enable;<br />
#encrypt enable;<br />
}<br />
<br />
=== Choosing a PIN Helper ===<br />
From all the other HOWTO's I read, I got the impression that the /usr/bin/bluepin script supplied with the Bluez-utils was junk. I found a nice, simple replacement script on this page http://orin.meinlschmidt.org/~znouza/doc/r51/. I will duplicate it here just for ease, but all rights and respect go to whoever made that page. Use your favorite text editor and create the new file /usr/bin/pin:<br />
#!/bin/bash<br />
# original script from http://orin.meinlschmidt.org/~znouza/doc/r51/<br />
cat /etc/bluetooth/pin<br />
when you are done editing, save and close the file, then make it executable. Choose your permissions wisely.<br />
# chmod 710 /usr/bin/pin<br />
# ls -la /usr/bin/pin<br />
-rwx--x--- 1 root root 35 2006-04-09 19:19 /usr/bin/pin<br />
This /usr/bin/pin script will suffice for pretty much any way you want to connect to your phone. If you want to use kdebluetooth to connect to your phone, then use kbluepin. The example hcid.conf file above is already setup to use kbluepin. To use /usr/bin/pin, simply comment out the kbluepin line and remove the comment character(#) from the /usr/bin/pin line.<br />
<br />
=== Making the Connection ===<br />
Next, you need to start up the hcid and sdpd daemons. It is a good idea to add these to /etc/rc.d/rc.local so they start automatically with each reboot. At the command line type:<br />
# /usr/sbin/hcid<br />
# /usr/sbin/sdpd<br />
and add these lines to /etc/rc.d/rc.local<br />
/usr/sbin/hcid<br />
/usr/sbin/sdpd<br />
Then, you can set your phone to "discover" mode, allowing other devices to see it is present, and scan for it. On the Motorola V551 you go to Settings > Connection > Bluetooth Link > Setup > Find Me.<br />
# hcitool scan<br />
Scanning ...<br />
00:12:34:56:78:9A Motorola Phone<br />
Using the hardware address from the scan above, you can find out a lot of information about your phone.<br />
# sdptool records 00:12:34:56:78:9A<br />
Service Name: Dial-up networking Gateway<br />
Service Description: Dial-up networking Gateway<br />
Service Provider: Cingular<br />
Service RecHandle: 0x10001<br />
Service Class ID List:<br />
"Dialup Networking" (0x1103)<br />
Protocol Descriptor List:<br />
"L2CAP" (0x0100)<br />
"RFCOMM" (0x0003)<br />
Channel: 1<br />
Language Base Attr List:<br />
code_ISO639: 0x656e<br />
encoding: 0x6a<br />
base_offset: 0x100<br />
code_ISO639: 0x6672<br />
encoding: 0x6a<br />
base_offset: 0xd800<br />
code_ISO639: 0x6573<br />
encoding: 0x6a<br />
base_offset: 0xd803<br />
code_ISO639: 0x7074<br />
encoding: 0x6a<br />
base_offset: 0xd806<br />
Profile Descriptor List:<br />
"Dialup Networking" (0x1103)<br />
Version: 0x0100<br />
<br />
Service Name: Voice Gateway<br />
Service Description: Headset Audio Gateway<br />
Service Provider: Cingular<br />
Service RecHandle: 0x10003<br />
Service Class ID List:<br />
"Headset Audio Gateway" (0x1112)<br />
"Generic Audio" (0x1203)<br />
Protocol Descriptor List:<br />
"L2CAP" (0x0100)<br />
"RFCOMM" (0x0003)<br />
Channel: 3<br />
Language Base Attr List:<br />
code_ISO639: 0x656e<br />
encoding: 0x6a<br />
base_offset: 0x100<br />
code_ISO639: 0x6672<br />
encoding: 0x6a<br />
base_offset: 0xd800<br />
code_ISO639: 0x6573<br />
encoding: 0x6a<br />
base_offset: 0xd803<br />
code_ISO639: 0x7074<br />
encoding: 0x6a<br />
base_offset: 0xd806<br />
Profile Descriptor List:<br />
"Headset" (0x1108)<br />
Version: 0x0100<br />
<br />
Service Name: Hands-Free voice gateway<br />
Service Description: Hands-Free voice gateway<br />
Service Provider: Cingular<br />
Service RecHandle: 0x10007<br />
Service Class ID List:<br />
"Handfree Audio Gateway" (0x111f)<br />
"Generic Audio" (0x1203)<br />
Protocol Descriptor List:<br />
"L2CAP" (0x0100)<br />
"RFCOMM" (0x0003)<br />
Channel: 7<br />
Language Base Attr List:<br />
code_ISO639: 0x656e<br />
encoding: 0x6a<br />
base_offset: 0x100<br />
code_ISO639: 0x6672<br />
encoding: 0x6a<br />
base_offset: 0xd800<br />
code_ISO639: 0x6573<br />
encoding: 0x6a<br />
base_offset: 0xd803<br />
code_ISO639: 0x7074<br />
encoding: 0x6a<br />
base_offset: 0xd806<br />
Profile Descriptor List:<br />
"Handsfree" (0x111e)<br />
Version: 0x0101<br />
<br />
Service Name: OBEX Object Push<br />
Service Description: OBEX Object Push<br />
Service Provider: Cingular<br />
Service RecHandle: 0x10008<br />
Service Class ID List:<br />
"OBEX Object Push" (0x1105)<br />
Protocol Descriptor List:<br />
"L2CAP" (0x0100)<br />
"RFCOMM" (0x0003)<br />
Channel: 8<br />
"OBEX" (0x0008)<br />
Language Base Attr List:<br />
code_ISO639: 0x656e<br />
encoding: 0x6a<br />
base_offset: 0x100<br />
code_ISO639: 0x6672<br />
encoding: 0x6a<br />
base_offset: 0xd800<br />
code_ISO639: 0x6573<br />
encoding: 0x6a<br />
base_offset: 0xd803<br />
code_ISO639: 0x7074<br />
encoding: 0x6a<br />
base_offset: 0xd806<br />
Profile Descriptor List:<br />
"OBEX Object Push" (0x1105)<br />
Version: 0x0100<br />
<br />
Service Name: OBEX File Transfer<br />
Service Description: OBEX File Transfer<br />
Service Provider: Cingular<br />
Service RecHandle: 0x10009<br />
Service Class ID List:<br />
"OBEX File Transfer" (0x1106)<br />
Protocol Descriptor List:<br />
"L2CAP" (0x0100)<br />
"RFCOMM" (0x0003)<br />
Channel: 9<br />
"OBEX" (0x0008)<br />
Language Base Attr List:<br />
code_ISO639: 0x656e<br />
encoding: 0x6a<br />
base_offset: 0x100<br />
code_ISO639: 0x6672<br />
encoding: 0x6a<br />
base_offset: 0xd800<br />
code_ISO639: 0x6573<br />
encoding: 0x6a<br />
base_offset: 0xd803<br />
code_ISO639: 0x7074<br />
encoding: 0x6a<br />
base_offset: 0xd806<br />
Profile Descriptor List:<br />
"OBEX File Transfer" (0x1106)<br />
Version: 0x0100<br />
<br />
=== Radio Frequency Communication (RFCOMM) ===<br />
This is one way to use your phone as a modem. I believe that most Cingular and T-Mobile (GSM/GPRS) in the USA use channel 1 for the Dial-Up Gateway. One way to take advantage of this is to use rfcomm to connect to your phone. In order to do that, you will need to edit /etc/bluetooth/rfcomm.conf:<br />
#<br />
# RFCOMM configuration file.<br />
#<br />
rfcomm0 {<br />
# Automatically bind the device at startup<br />
bind yes;<br />
# Bluetooth address of the device<br />
device 00:12:34:56:78:9A;<br />
# RFCOMM channel for the connection<br />
channel 1;<br />
# Description of the connection<br />
comment "Motorola V551";<br />
}<br />
Then connect to the phone by typing:<br />
# rfcomm connect 0<br />
I won't go in to any more details because I don't use my phone as a modem. But, if you want to use your phone that way, there are plenty of resources out there to show you what to do.<br />
<br />
=== KDE Bluetooth ===<br />
I don't use KDE as my window manager/desktop, but kdebluetooth should automatically run when you start KDE. If you don't use KDE, like me, you can start up the taskbar daemon by typing "kbluetoothd" in a terminal. You can then use the KDE OBEX Push Client to transfer files to your phone. I haven't figured out how to get files off of my phone (like pictures), but I have seen [http://openobex.triq.net/obexftp/obexftp obexftp] and [http://openobex.triq.net/obexfs obexfs] which look promising. When I test those out, I will update this accordingly.<br />
<br />
== References ==<br />
http://www.linuxquestions.org/hcl/showproduct.php?product=2879&cat=53<br />
<br />
http://www.westmaster.com/zidek/p900/bluetooth/<br />
<br />
http://www.bluez.org<br />
<br />
http://www.develia.org/tarballs.php?p=networking<br />
<br />
http://kde-bluetooth.sourceforge.net/<br />
<br />
http://extragear.kde.org/<br />
<br />
http://www.gentoo.org/doc/en/bluetooth-guide.xml</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Btfirmware-nonfree&diff=981Btfirmware-nonfree2015-11-25T04:15:21Z<p>Rworkman: Created page with "I recently was presented with a Thinkpad T430s containing a Broadcom BCM20702 bluetooth chip, and bluetooth wouldn't work at all on it. <code>$ lsusb Bus 003 Device 009: ID 0..."</p>
<hr />
<div>I recently was presented with a Thinkpad T430s containing a Broadcom BCM20702 bluetooth chip, and bluetooth wouldn't work at all on it.<br />
<br />
<code>$ lsusb<br />
Bus 003 Device 009: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]<br />
</code><br />
<br />
On boot, I saw this in /var/log/syslog: <br /><br />
<code>Nov 24 13:37:35 liberty kernel: bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e6.hcd failed with error -2</code> <br /><br />
Sure enough, /lib/firmware/brcm/BCM20702A1-0a5c-21e6.hcd did not exist.<br />
<br />
After a bit of research, I determined that nobody had already written clear instructions on just how to obtain the needed firmware. There were a few results with links to different firmware that someone had already obtained from some mysterious source, and vague references about "get it from your Windows system" and such, but well, I don't have a Windows system.<br />
<br />
I went to the Lenovo support site, downloaded the bluetooth driver file (currently located at https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/g4wb12ww.exe but of course, this link will not always be valid), and poked around a bit in its contents. To do that, you'll first need to get innoextract (see http://constexpr.org/innoextract/ or search SlackBuilds.org for it).<br />
<br /><br />
<code><br />
root@liberty:~/fw# ls <br /><br />
g4wb12ww.exe <br /><br />
root@liberty:~/fw# innoextract g4wb12ww.exe <br /><br />
...lots of output, all extracted to an "app/" directory... <br /><br />
</code> <br /><br />
<br />
Now to see if we can find the important bits in here... I notice that the firmware expected to be loaded has "0a5c-21e6" in the name, and the usb ID of the bluetooth hardware is "0a5c:21e6" so let's poke around and see if we can find anything with that name: <br /> <br /><br />
<code>find app/ -name "*0a5c*" -o -name "*0A5C*"</code> <br /> <br /><br />
Hmm, no output. Okay. <br /> <br /><br />
<code> <br /><br />
root@liberty:~/fw#grep -Eir 0a5c.*21e6 . <br /><br />
Binary file ./app/Win64/BTW.msi matches <br /><br />
./app/Win64/bcbtums-win7x64-brcm.inf:%BRCM20702Thinkpad.DeviceDesc%=RAMUSB21E6, USB\VID_0A5C&PID_21E6 ; 20702 non-UHE Lenovo Japan <br /><br />
Binary file ./app/Win32/BTW.msi matches <br /><br />
./app/Win32/bcbtums-win7x86-brcm.inf:%BRCM20702Thinkpad.DeviceDesc%=RAMUSB21E6, USB\VID_0A5C&PID_21E6 ; 20702 non-UHE Lenovo Japan <br /><br />
</code> <br /> <br /><br />
Well, I don't want to poke around in binary files too much, but I know that .inf are plaintext files, so let's look in there. That "DeviceDesc" looks important, so we'll search for that in the .inf file once we get it opened. I use vi, but hopefully you know your editor well enough to do the equivalent, and you'll find something like this: <br /> <br /><br />
<br />
<code><br />
... <br /><br />
%BRCM20702Thinkpad.DeviceDesc%=RAMUSB21E6, USB\VID_0A5C&PID_21E6 ; 20702 non-UHE Lenovo Japan <br /><br />
... <br /><br />
;;;;;;;;;;;;;RAMUSB21E6;;;;;;;;;;;;;;;;; <br /><br />
<br /><br />
[RAMUSB21E6.CopyList]<br /><br />
bcbtums.sys<br /><br />
BCM20702A1_001.002.014.0449.0462.hex<br /><br />
<br /><br />
[RAMUSB21E6.NTX86]<br /><br />
Include=bth.inf<br /><br />
Needs=BthUsb.NT<br /><br />
FeatureScore=F0<br /><br />
CopyFiles=RAMUSB21E6.CopyList<br /><br />
<br /><br />
[RAMUSB21E6.NTX86.hw]<br /><br />
AddReg=RAMUSB21E6.NTX86.hw.reg<br /><br />
<br /><br />
[RAMUSB21E6.NTX86.hw.reg]<br /><br />
HKR,,LowerFilters, 0x00010000, "bcbtums"<br /><br />
HKR,,%RAMPatchFileName%,0x00000, "BCM20702A1_001.002.014.0449.0462.hex"<br /><br />
HKR,,%RemoteWakeEnabled%,0x00010001,1<br /><br />
HKR,,%DeviceRemoteWakeSupported%,0x00010001,1<br /><br />
<br /><br />
[RAMUSB21E6.NTX86.Services]<br /><br />
needs=BthUsb.NT.Services<br /><br />
AddService=bcbtums,,BCBTUMS_Service_Inst, BTWSECFL_EventLog_Inst<br /><br />
<br /><br />
... <br /><br />
</code><br />
<br /><br />
I happen to know from my research that the firmware files are .hex file, so this line is awesome to see: <br /><br />
<code>HKR,,%RAMPatchFileName%,0x00000, "BCM20702A1_001.002.014.0449.0462.hex"</code><br />
<br /><br />
<br />
Copy that file out of the directory structure into a place that's easier to work with:<br /><br />
<code><br />
root@liberty:~/fw# cp app/Win64/BCM20702A1_001.002.014.0449.0462.hex . <br /><br />
root@liberty:~/fw# ls <br /><br />
BCM20702A1_001.002.014.0449.0462.hex app/ g4wb12ww.exe <br /><br />
</code><br />
<br /><br />
Now we need to put this in a form that the linux kernel expects, so that's where hex2hcd comes in: <br /><br />
<code><br />
root@liberty:~/fw# git clone git://github.com/jessesung/hex2hcd.git <br /><br />
Cloning into 'hex2hcd'...<br /><br />
remote: Counting objects: 8, done.<br /><br />
remote: Compressing objects: 100% (7/7), done.<br /><br />
remote: Total 8 (delta 1), reused 8 (delta 1), pack-reused 0<br /><br />
Receiving objects: 100% (8/8), 8.71 KiB | 0 bytes/s, done.<br /><br />
Resolving deltas: 100% (1/1), done.<br /><br />
Checking connectivity... done.<br /><br />
root@liberty:~/fw# cd hex2hcd/<br /><br />
root@liberty:~/fw/hex2hcd# make<br /><br />
gcc -O2 -march=native hex2hcd.c -o hex2hcd<br /><br />
</code><br />
<br />
Now we use hex2hcd:<br />
<code><br />
root@liberty:~/fw/hex2hcd# ./hex2hcd ../BCM20702A1_001.002.014.0449.0462.hex ../BCM20702A1-0a5c-21e6.hcd <br /><br />
... lots of text and binary data ...<br /><br />
</code><br />
<br />
Finally, let's back up a directory, make sure what think is there is actually there, and copy it into place:<br />
<br />
<code><br />
root@liberty:~/fw/hex2hcd# cd ..<br /><br />
root@liberty:~/fw# ls<br /><br />
BCM20702A1-0a5c-21e6.hcd BCM20702A1_001.002.014.0449.0462.hex app/ g4wb12ww.exe hex2hcd/<br /><br />
root@liberty:~/fw# cp BCM20702A1-0a5c-21e6.hcd /lib/firmware/brcm/<br /><br />
</code><br />
<br />
The first person who finds this useful is expected to clean up the formatting and such. :-) Enjoy! -RW</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Cgroups_with_KVM_and_Libvirt&diff=965Cgroups with KVM and Libvirt2015-05-18T00:24:05Z<p>Rworkman: /* Using cgroups in Slackware with KVM/Libvirt */</p>
<hr />
<div>=Using cgroups in Slackware with KVM/Libvirt=<br />
<br />
Hello friends, I’ve been using KVM a lot of months until now and every new host server that I create I need to change the way of how Slackware seems to create cgroups, libvirt doesn’t function very good if you don’t create specific directories in ‘/sys/fs/cgroup’ tree. So, to do that for me I made this script below<br />
<br />
<pre># cat /etc/rc.d/rc.cgroup<br />
<br />
#!/bin/sh<br />
#<br />
# /etc/rc.d/rc.cgroup: cgroups init script<br />
# Alexandre Mulatinho <alex@mulatinho.net><br />
# Unmount /sys/fs/cgroup<br />
umount /sys/fs/cgroup<br />
<br />
# Mount cgroup_root in /sys/fs/cgroup<br />
mount -t tmpfs -o mode=755,rw cgroup_root /sys/fs/cgroup/<br />
<br />
# Mount all the subsystems available in /sys/fs/cgroup as individual directory<br />
for i in $(lssubsys -a);<br />
do<br />
mkdir -pv /sys/fs/cgroup/$i<br />
mount -v -t cgroup -o $i $i /sys/fs/cgroup/$i<br />
done<br />
<br />
# chmod u+x /etc/rc.d/rc.cgroup</pre><br />
<br />
And now everytime my slackware system boot, my cgroups tree are build in right way that KVM and libvirt can use him to manipulate things like memory, cpu, io, disk, etc. Hope it helps someone else :-)<br />
<br />
* EDIT: (from rworkman)<br />
This is not really the place to have such a question, but I don't find this to be necessary here (on a Slackware 14.1 system):<br />
<pre><br />
root@fs:~# grep cgroup /proc/mounts <br />
cgroup_root /sys/fs/cgroup tmpfs rw,relatime,mode=755 0 0<br />
cpuset /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0<br />
cpu /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0<br />
cpuacct /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0<br />
blkio /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0<br />
memory /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0<br />
devices /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0<br />
freezer /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0<br />
net_cls /sys/fs/cgroup/net_cls cgroup rw,relatime,net_cls 0 0<br />
perf_event /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0<br />
net_prio /sys/fs/cgroup/net_prio cgroup rw,relatime,net_prio 0 0<br />
</pre><br />
* END EDIT<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Main_Page&diff=962Main Page2014-10-28T16:18:50Z<p>Rworkman: Reverted edits by Rworkman (talk) to last revision by Erik</p>
<hr />
<div>Welcome to slackwiki! Feel free to [[Special:Userlogin|Create an account or log in]] and edit any of the pages, or add your own (see [http://meta.wikimedia.org/wiki/Help:Starting_a_new_page Starting A New Page]). Come talk to some of us in ##slackware on irc.freenode.net. When saving changes, please provide a brief summary of your changes in the box provided - it's nice for those sad people who follow [[Special:Recentchanges|RecentChanges]] via RSS. Any questions about the wiki? See the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide User's Guide].<br />
<br />
==Main Sections==<br />
Please [[Special:Userlogin|LOG IN]] before adding/editing pages.<br />
<br />
* [[:Category:Information|Information]]<br />
* [[:Category:Tutorials|Tutorials]]<br />
* [[:Category:Tips|Tips]]<br />
* [[:Category:Security|Security]]<br />
* [[:Category:Hardware|Hardware]]<br />
* [[Links]]<br />
<hr style="width:20em"/><br />
* [[The Regulars|Regulars of Freenode ##slackware]]<br />
* [[Contest|Logo Contest]] (Finished)<br />
<br />
==Thanks==<br />
* '''Anyone who contributes to the wiki :)'''<br />
<br />
==News==<br />
MediaWiki was upgraded to 1.23.5. --[[User:Erik|Erik]] ([[User talk:Erik|talk]]) 19:34, 26 October 2014 (EDT)<br />
<br />
MediaWiki was upgraded to 1.19.0. --[[User:Erik|Erik]] ([[User talk:Erik|talk]]) 00:30, 1 June 2012 (EDT)<br />
<br />
MediaWiki was upgraded to 1.18.0. --[[User:Erik|Erik]] 03:44, 17 December 2011 (CST)<br />
<br />
Patched to 1.16.2. --[[User:Erik|Erik]] 18:53, 1 February 2011 (EST) | Patched to 1.16.5. --[[User:Erik|Erik]] 17:55, 13 June 2011 (CDT)<br />
<br />
MediaWiki was upgraded to 1.16.1. --[[User:Erik|Erik]] 11:43, 5 January 2011 (CST)<br />
<br />
Patched to 1.15.3. --[[User:Erik|Erik]] 09:33, 7 April 2010 (UTC) | Patched to 1.15.4. --[[User:Erik|Erik]] 08:31, 30 May 2010 (UTC)<br />
| Patched to 1.15.5. --[[User:Erik|Erik]] 23:12, 28 July 2010 (UTC)<br />
<br />
MediaWiki was upgraded to 1.15.2. --[[User:Erik|Erik]] 00:25, 9 March 2010 (UTC)<br />
<br />
Sorry for the temporary downtime - we forgot to renew the domain name registration. --[[User:rworkman|rworkman]] 0006, 3 November 2009 (UTC)<br />
<br />
There has been a reset of the wiki. The database was corrupted. A few pages, all Talk/Discussion pages and all user accounts were lost. --[[User:Erik|Erik]] 23:44, 6 June 2009 (UTC)<br />
<br />
MediaWiki was upgraded to 1.14.0 --[[User:Erik|Erik]] 16:49, 16 March 2009 (UTC)<br />
<br />
We've moved! We're now hosted by [http://onyxlight.net/ http://onyxlight.net/] with an upgrade to MediaWiki 1.6.6 and<br />
spambot prevention in place. --[[User:Erik|Erik]] 11:33, 22 May 2006 (GMT)<br />
<br />
The contest has been won by [[User:Marcus|Marcus]]. Admire the logo :) --[[User:FredEmmott|FredEmmott]] 12:36, 24 Feb 2005 (GMT)<br />
<br />
Updated SlackWiki to MediaWiki 1.4.7 --[[User:FredEmmott|FredEmmott]] 12:01, 21 Jul 2005 (GMT)<br />
<br />
We're now sharing [http://cardinal.lizella.net cardinal.lizella.net] with several other Slackware projects such as [http://www.slacksec.org SlackSec], the [http://www.slackbook.org Slackware Book Project], and [http://www.slamd64.com Slamd64]. Hopefully this will mean a more reliable and faster wiki --[[User:FredEmmott|FredEmmott]] 19:42, 2 May 2005 (GMT)<br />
<br />
We're back onto my little UML temporarily, but I've finally judged the contest,<br />
congratulations to [[User:Marcus|Marcus]]. Next artwork contest comming soon, please use the [[Talk:Main_Page|main talk page]] for suggestions on more technical contests --[[User:FredEmmott|FredEmmott]] 18:36, 24 Feb 2005 (GMT)<br />
<br />
Thanks to RackSpace and Michael Shuler - they've generously donated a dedicated server to http://www.slacksec.org, which slackwiki is sharing --[[User:FredEmmott|FredEmmott]] 15:06, 1 Dec 2004 (CST)<br />
<br />
We are now sharing this server with http://www.slacksec.info - security updates in Pat's absence --[[User:FredEmmott|FredEmmott]] 22:22, 19 Nov 2004 (GMT)<br />
<br />
We should not have as many problems with server now - I have no choice but to run debian on this server, and apparantly they missed backporting a security patch, so it's now on traditional non-debianified apache 1.3.33 :) --[[User:FredEmmott|FredEmmott]] 18:03, 2 Nov 2004 (GMT)<br />
<br />
Please feel free to bring our old pages over from [http://slackwiki.org/old/index.php?pagename=HomePage the old site] --[[User:FredEmmott|FredEmmott]] 21:23, 31 Oct 2004 (GMT)<br />
<br />
Swapped wiki software again because PHPWiki is too buggy --[[User:FredEmmott|FredEmmott]] 21:11, 31 Oct 2004 (GMT)</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Main_Page&diff=961Main Page2014-10-28T16:18:07Z<p>Rworkman: Reverted edits by Erik (talk) to last revision by Rworkman</p>
<hr />
<div>Welcome to slackwiki! Feel free to [[Special:Userlogin|Create an account or log in]] and edit any of the pages, or add your own (see [http://meta.wikimedia.org/wiki/Help:Starting_a_new_page Starting A New Page]). Come talk to some of us in ##slackware on irc.freenode.net. When saving changes, please provide a brief summary of your changes in the box provided - it's nice for those sad people who follow [[Special:Recentchanges|RecentChanges]] via RSS. Any questions about the wiki? See the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide User's Guide].<br />
<br />
==Main Sections==<br />
Please [[Special:Userlogin|LOG IN]] before adding/editing pages.<br />
<br />
* [[:Category:Information|Information]]<br />
* [[:Category:Tutorials|Tutorials]]<br />
* [[:Category:Tips|Tips]]<br />
* [[:Category:Security|Security]]<br />
* [[:Category:Hardware|Hardware]]<br />
* [[Links]]<br />
<hr style="width:20em"/><br />
* [[The Regulars|Regulars of Freenode ##slackware]]<br />
* [[Contest|Logo Contest]] (Finished)<br />
<br />
==Thanks==<br />
* '''Anyone who contributes to the wiki :)'''<br />
<br />
==News==<br />
Sorry for the temporary downtime - we forgot to renew the domain name registration. --[[User:rworkman|rworkman]] 0006, 3 November 2009 (UTC)<br />
<br />
There has been a reset of the wiki. The database was corrupted. A few pages, all Talk/Discussion pages and all user accounts were lost. --[[User:Erik|Erik]] 23:44, 6 June 2009 (UTC)<br />
<br />
MediaWiki was upgraded to 1.14.0 --[[User:Erik|Erik]] 16:49, 16 March 2009 (UTC)<br />
<br />
We've moved! We're now hosted by [http://onyxlight.net/ http://onyxlight.net/] with an upgrade to MediaWiki 1.6.6 and<br />
spambot prevention in place. --[[User:Erik|Erik]] 11:33, 22 May 2006 (GMT)<br />
<br />
The contest has been won by [[User:Marcus|Marcus]]. Admire the logo :) --[[User:FredEmmott|FredEmmott]] 12:36, 24 Feb 2005 (GMT)<br />
<br />
Updated SlackWiki to MediaWiki 1.4.7 --[[User:FredEmmott|FredEmmott]] 12:01, 21 Jul 2005 (GMT)<br />
<br />
We're now sharing [http://cardinal.lizella.net cardinal.lizella.net] with several other Slackware projects such as [http://www.slacksec.org SlackSec], the [http://www.slackbook.org Slackware Book Project], and [http://www.slamd64.com Slamd64]. Hopefully this will mean a more reliable and faster wiki --[[User:FredEmmott|FredEmmott]] 19:42, 2 May 2005 (GMT)<br />
<br />
We're back onto my little UML temporarily, but I've finally judged the contest,<br />
congratulations to [[User:Marcus|Marcus]]. Next artwork contest comming soon, please use the [[Talk:Main_Page|main talk page]] for suggestions on more technical contests --[[User:FredEmmott|FredEmmott]] 18:36, 24 Feb 2005 (GMT)<br />
<br />
Thanks to RackSpace and Michael Shuler - they've generously donated a dedicated server to http://www.slacksec.org, which slackwiki is sharing --[[User:FredEmmott|FredEmmott]] 15:06, 1 Dec 2004 (CST)<br />
<br />
We are now sharing this server with http://www.slacksec.info - security updates in Pat's absence --[[User:FredEmmott|FredEmmott]] 22:22, 19 Nov 2004 (GMT)<br />
<br />
We should not have as many problems with server now - I have no choice but to run debian on this server, and apparantly they missed backporting a security patch, so it's now on traditional non-debianified apache 1.3.33 :) --[[User:FredEmmott|FredEmmott]] 18:03, 2 Nov 2004 (GMT)<br />
<br />
Please feel free to bring our old pages over from [http://slackwiki.org/old/index.php?pagename=HomePage the old site] --[[User:FredEmmott|FredEmmott]] 21:23, 31 Oct 2004 (GMT)<br />
<br />
Swapped wiki software again because PHPWiki is too buggy --[[User:FredEmmott|FredEmmott]] 21:11, 31 Oct 2004 (GMT)</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Talk:Broadcom_Wireless&diff=906Talk:Broadcom Wireless2014-04-03T03:44:38Z<p>Rworkman: </p>
<hr />
<div>I just made a couple of relatively minor edits to the page (20140402):<br />
First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:<br />
Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it. --rworkman</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Talk:Broadcom_Wireless&diff=905Talk:Broadcom Wireless2014-04-03T03:44:05Z<p>Rworkman: Explanation of changes wrt /etc/modprobe.d/</p>
<hr />
<div>I just made a couple of relatively minor edits to the page (20140402):<br />
First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:<br />
Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it.</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Broadcom_Wireless&diff=904Broadcom Wireless2014-04-03T03:38:04Z<p>Rworkman: /* Blacklisting the b43 and ssb modules */</p>
<hr />
<div>[[Category:Tutorials]]<br />
== Introduction ==<br />
<br />
This tutorial is written for setting up wireless on Slackware on laptops with Broadcom wireless cards. It deals with installing Boradcom's official proprietary '''wl''' driver for Linux that includes support for Broadcom's BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based hardware.<br />
<br />
== Prerequisites ==<br />
<br />
This tutorial assumes a full Slackware installation. There should also be a way to transfer files to the target laptop - it can either be a working internet connection using the laptop's ethernet card, '''or''' a different machine with internet access and a USB thumb drive to transfer the files.<br />
The regular user account on the laptop must also be a part of the ''netdev'' group.<br />
<br />
== Getting Started ==<br />
<br />
The first thing is to check if the user is part of the ''netdev'' group :<br />
<br />
<pre>groups</pre><br />
<br />
If the output does not contain <code>netdev</code>, then as <code>root</code>, enter the following command :<br />
<br />
<pre>usermod -a -G netdev username</pre><br />
<br />
where <code>username</code> is the name of your user account.<br />
<br />
== Installing the driver ==<br />
<br />
=== Sbopkg method ===<br />
If a working internet connection is available on the laptop (say a wired connection), use [http://sbopkg.org sbopkg] to install the drivers :<br />
<pre>sbopkg -i broadcom-sta</pre><br />
<br />
=== Manual method ===<br />
Navigate to the slackbuilds.org's [http://slackbuilds.org/result/?search=broadcom-sta&sv= broadcom-sta page] and build the package according to the [http://slackbuilds.org/howto/ instructions] given. Make sure to download the source code relevant to the architecture of your installation (32-bit or 64-bit).<br />
<br />
=== Kernel upgrade ===<br />
<br />
If at any point you upgrade your kernel, you will have to do this process again, because the module is compiled against the running kernel only.<br />
<br />
== Blacklisting the b43 and ssb modules ==<br />
<br />
The Broadcom's <code>wl</code> driver conflicts with the kernel's <code>b43</code> driver, so create the <code>/etc/modprobe.d/b43-blacklist.conf</code> file (name doesn't matter, but it's nice to have something intuitive) using the text editor of your choice as <code>root</code> and add the following lines to it :<br />
<br />
<pre><br />
blacklist ssb<br />
blacklist b43<br />
blacklist bcma<br />
</pre><br />
<br />
== Final steps ==<br />
<br />
At this point, reboot your machine. The drivers should be installed and work now. To test this, enter the <code>iwconfig</code> command. you should see an output like this :<br />
<br />
<pre><br />
$ iwconfig<br />
lo no wireless extensions.<br />
<br />
eth1 IEEE 802.11 Nickname:"lapto"<br />
Access Point: Not-Associated <br />
Link Quality:5 Signal level:217 Noise level:199<br />
Rx invalid nwid:0 invalid crypt:31 invalid misc:0<br />
<br />
eth0 no wireless extensions.<br />
</pre><br />
<br />
This output suggests that the drivers installed right and your wireless card is recognized as <code>eth1</code> by the kernel. Hooray!<br />
<br />
If you still don't see the wireless extensions, check if any of the blacklisted modules are really not loaded:<br />
<pre><br />
lsmod | grep ssb<br />
lsmod | grep b43<br />
lsmod | grep bcma<br />
</pre><br />
<br />
None of this commands should return anything. If any of the modules are still loaded, remove them manually:<br />
<pre><br />
rmmod ssb<br />
rmmod b43<br />
rmmod bcma<br />
</pre><br />
<br />
You can also make sure that the "wl" module is properly loaded<br />
<pre><br />
lsmod | grep wl<br />
</pre><br />
<br />
If there is no output, you may load the "wl" module manually<br />
<pre><br />
modprobe wl<br />
</pre><br />
<br />
<br />
You can now either use the <code>iwconfig</code> tool to configure your wireless networks, '''or''' if you prefer to use a GUI, follow the next section for installing Wicd.<br />
<br />
== Installing Wicd ==<br />
<br />
To make management of wireless connections easier, we will install [http://wicd.sourceforge.net/ Wicd] network manager that provides a simple configuration GUI and system tray icon.<br />
<br />
=== Using slackpkg ===<br />
<br />
If a working internet connection is available on the laptop (say a wired connection), simply use <code>slackpkg</code> to install wicd :<br />
<pre>slackpkg install wicd</pre><br />
<br />
=== Using package tarball ===<br />
<br />
Download the <code>Wicd</code> package for your Slackware version from the ''extra/'' section of your preferred Slackware [http://slackware.osuosl.org/ mirror] and install using <code>installpkg</code>.<br />
<br />
For example, on a 32-bit system running Slackware 13.37, as root:<br />
<br />
<pre><br />
wget http://slackware.dreamhost.com/slackware/slackware-13.37/extra/wicd/wicd-1.7.0-i486-2.txz<br />
installpkg ./wicd-1.7.0-i486-2.txz<br />
</pre><br />
<br />
== Wicd usage ==<br />
Start the Wicd daemon :<br />
<br />
<pre><br />
/etc/rc.d/rc.wicd start<br />
</pre><br />
<br />
Once its started, run <code>wicd-client</code> and configure the network to your liking.<br />
<br />
=== Caveat ===<br />
Wicd by default treats <code>wlan0</code> as the default wireless interface. Since the interface is <code>eth1</code> in our case, you might want to correct this in Wicd's Preferences.<br />
<br />
=== User note ===<br />
In order to access the wicd client utilities, your user must also be in the netdev group. Add your user to the netdev group, logout and login to make it effective, then you can run the wicd client utilities as your user.<br />
For the CLI based tool, there is wicd-cli and wicd-curses. For the GUI client, ther is wicd-client and wicd-gtk.</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Broadcom_Wireless&diff=903Broadcom Wireless2014-04-03T03:36:33Z<p>Rworkman: Do not edit files in /lib/modprobe.d/ - they are overwritten on upgrades</p>
<hr />
<div>[[Category:Tutorials]]<br />
== Introduction ==<br />
<br />
This tutorial is written for setting up wireless on Slackware on laptops with Broadcom wireless cards. It deals with installing Boradcom's official proprietary '''wl''' driver for Linux that includes support for Broadcom's BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based hardware.<br />
<br />
== Prerequisites ==<br />
<br />
This tutorial assumes a full Slackware installation. There should also be a way to transfer files to the target laptop - it can either be a working internet connection using the laptop's ethernet card, '''or''' a different machine with internet access and a USB thumb drive to transfer the files.<br />
The regular user account on the laptop must also be a part of the ''netdev'' group.<br />
<br />
== Getting Started ==<br />
<br />
The first thing is to check if the user is part of the ''netdev'' group :<br />
<br />
<pre>groups</pre><br />
<br />
If the output does not contain <code>netdev</code>, then as <code>root</code>, enter the following command :<br />
<br />
<pre>usermod -a -G netdev username</pre><br />
<br />
where <code>username</code> is the name of your user account.<br />
<br />
== Installing the driver ==<br />
<br />
=== Sbopkg method ===<br />
If a working internet connection is available on the laptop (say a wired connection), use [http://sbopkg.org sbopkg] to install the drivers :<br />
<pre>sbopkg -i broadcom-sta</pre><br />
<br />
=== Manual method ===<br />
Navigate to the slackbuilds.org's [http://slackbuilds.org/result/?search=broadcom-sta&sv= broadcom-sta page] and build the package according to the [http://slackbuilds.org/howto/ instructions] given. Make sure to download the source code relevant to the architecture of your installation (32-bit or 64-bit).<br />
<br />
=== Kernel upgrade ===<br />
<br />
If at any point you upgrade your kernel, you will have to do this process again, because the module is compiled against the running kernel only.<br />
<br />
== Blacklisting the b43 and ssb modules ==<br />
<br />
The Broadcom's <code>wl</code> driver conflicts with the kernel's <code>b43</code> driver, so open up the <code>/etc/modprobe.d/blacklist.conf</code> using the text editor of your choice as <code>root</code> and add the following lines to it :<br />
<br />
<pre><br />
blacklist ssb<br />
blacklist b43<br />
blacklist bcma<br />
</pre><br />
<br />
== Final steps ==<br />
<br />
At this point, reboot your machine. The drivers should be installed and work now. To test this, enter the <code>iwconfig</code> command. you should see an output like this :<br />
<br />
<pre><br />
$ iwconfig<br />
lo no wireless extensions.<br />
<br />
eth1 IEEE 802.11 Nickname:"lapto"<br />
Access Point: Not-Associated <br />
Link Quality:5 Signal level:217 Noise level:199<br />
Rx invalid nwid:0 invalid crypt:31 invalid misc:0<br />
<br />
eth0 no wireless extensions.<br />
</pre><br />
<br />
This output suggests that the drivers installed right and your wireless card is recognized as <code>eth1</code> by the kernel. Hooray!<br />
<br />
If you still don't see the wireless extensions, check if any of the blacklisted modules are really not loaded:<br />
<pre><br />
lsmod | grep ssb<br />
lsmod | grep b43<br />
lsmod | grep bcma<br />
</pre><br />
<br />
None of this commands should return anything. If any of the modules are still loaded, remove them manually:<br />
<pre><br />
rmmod ssb<br />
rmmod b43<br />
rmmod bcma<br />
</pre><br />
<br />
You can also make sure that the "wl" module is properly loaded<br />
<pre><br />
lsmod | grep wl<br />
</pre><br />
<br />
If there is no output, you may load the "wl" module manually<br />
<pre><br />
modprobe wl<br />
</pre><br />
<br />
<br />
You can now either use the <code>iwconfig</code> tool to configure your wireless networks, '''or''' if you prefer to use a GUI, follow the next section for installing Wicd.<br />
<br />
== Installing Wicd ==<br />
<br />
To make management of wireless connections easier, we will install [http://wicd.sourceforge.net/ Wicd] network manager that provides a simple configuration GUI and system tray icon.<br />
<br />
=== Using slackpkg ===<br />
<br />
If a working internet connection is available on the laptop (say a wired connection), simply use <code>slackpkg</code> to install wicd :<br />
<pre>slackpkg install wicd</pre><br />
<br />
=== Using package tarball ===<br />
<br />
Download the <code>Wicd</code> package for your Slackware version from the ''extra/'' section of your preferred Slackware [http://slackware.osuosl.org/ mirror] and install using <code>installpkg</code>.<br />
<br />
For example, on a 32-bit system running Slackware 13.37, as root:<br />
<br />
<pre><br />
wget http://slackware.dreamhost.com/slackware/slackware-13.37/extra/wicd/wicd-1.7.0-i486-2.txz<br />
installpkg ./wicd-1.7.0-i486-2.txz<br />
</pre><br />
<br />
== Wicd usage ==<br />
Start the Wicd daemon :<br />
<br />
<pre><br />
/etc/rc.d/rc.wicd start<br />
</pre><br />
<br />
Once its started, run <code>wicd-client</code> and configure the network to your liking.<br />
<br />
=== Caveat ===<br />
Wicd by default treats <code>wlan0</code> as the default wireless interface. Since the interface is <code>eth1</code> in our case, you might want to correct this in Wicd's Preferences.<br />
<br />
=== User note ===<br />
In order to access the wicd client utilities, your user must also be in the netdev group. Add your user to the netdev group, logout and login to make it effective, then you can run the wicd client utilities as your user.<br />
For the CLI based tool, there is wicd-cli and wicd-curses. For the GUI client, ther is wicd-client and wicd-gtk.</div>Rworkmanhttps://www.slackwiki.com/index.php?title=DVB&diff=901DVB2014-03-15T16:31:34Z<p>Rworkman: Reverted edits by Sinyorita (talk) to last revision by Count Zero</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
== Introduction ==<br />
I've been a big fan of tv tuner cards for almost as long as I've been in to computers. As soon as my dad bought an HDTV, I knew I had to have it, and the first chance I had was to buy the ATI HDTV Wonder card for my computer. Sure, the picture can be bad sometimes because you are grabbing the signal out of the air with an unamplified antenna, but it is well worth it. When I finally decided to make the jump to Linux a few months ago, I researched ahead of time if it was possible to use my card in Linux, and to my surprise I could. Let me note that it did take me a few months of on and off work to get it running since I was pretty much learning Linux from scratch along the way. The biggest pitfalls I ran in to was the lack of a complete HOWTO to lead me through the steps from start to finish and the lack of a large DVB/HDTV user community to ask for help when I ran in to trouble. I hope that this tutorial gets rid of those two pitfalls and lets you get your HDTV card working without any trouble.<br />
<br />
==Kernel Configuration ==<br />
I'm not sure which kernel exactly began including the necesary modules for the ATI HDTV Wonder card, but I do know that kernel versions 2.6.15 and up have them. In order to use the ATI HDTV Wonder, you need to enable the correct modules in the kernel. You need to enable I2C and the cx88 DVB modules under Device Drivers. If you are new to building your own kernel, see [[Kernel26Compilation]]<br />
<br />
snipped from my .config<br />
#<br />
# I2C support<br />
#<br />
CONFIG_I2C=m<br />
CONFIG_I2C_CHARDEV=m<br />
<br />
#<br />
# I2C Algorithms<br />
#<br />
CONFIG_I2C_ALGOBIT=m<br />
<br />
#<br />
# Video For Linux<br />
#<br />
<br />
#<br />
# Video Adapters<br />
#<br />
CONFIG_VIDEO_CX88=m<br />
CONFIG_VIDEO_CX88_ALSA=m<br />
CONFIG_VIDEO_CX88_DVB=m<br />
CONFIG_VIDEO_CX88_DVB_ALL_FRONTENDS=n<br />
CONFIG_VIDEO_CX88_VP3054=m<br />
#<br />
# Digital Video Broadcasting Devices<br />
#<br />
CONFIG_DVB=y<br />
CONFIG_DVB_CORE=m<br />
<br />
#<br />
# ATSC (North American/Korean Terresterial DTV) frontends<br />
#<br />
CONFIG_DVB_NXT200X=m<br />
<br />
If you are a less advanced user, it won't hurt anything if you select everything that might remotely deal with DVB as a Module (hit `M`). When you are done, save the configuration and compile the kernel. Before you reboot, you need to download the firmware for the card.<br />
<br />
== Firmware ==<br />
Make sure you are in /usr/src/linux<br />
# pwd<br />
/usr/src/linux<br />
There is a script provided that will download the appropriate firmware driver for you. First, make it executable, then run it.<br />
# chmod +x Documentation/dvb/get_dvb_firmware<br />
# ./Documentation/dvb/get_dvb_firmware nxt2004<br />
Then the firmware file needs to be copied to the directory where hotplug will find it. On Slackware, this directory is /lib/firmware<br />
# cp dvb-fe-nxt2004.fw /lib/firmware<br />
Now you can reboot in to your new kernel, and your card should be automatically recognized. You can check to see if the modules loaded with lsmod<br />
$ lsmod | grep cx88<br />
cx88_dvb 8964 0<br />
cx8802 8068 1 cx88_dvb<br />
cx88xx 54180 2 cx88_dvb,cx8802<br />
ir_common 7812 1 cx88xx<br />
btcx_risc 3848 2 cx8802,cx88xx<br />
tveeprom 12304 1 cx88xx<br />
cx88_vp3054_i2c 3456 1 cx88_dvb<br />
i2c_algo_bit 7432 2 cx88xx,cx88_vp3054_i2c<br />
mt352 5380 1 cx88_dvb<br />
or51132 8324 1 cx88_dvb<br />
video_buf_dvb 4228 1 cx88_dvb<br />
video_buf 15364 4 cx88_dvb,cx8802,cx88xx,video_buf_dvb<br />
nxt200x 11524 1 cx88_dvb<br />
cx24123 7684 1 cx88_dvb<br />
lgdt330x 6684 1 cx88_dvb<br />
cx22702 5252 1 cx88_dvb<br />
i2c_core 15248 15 nvidia,w83627hf,eeprom,i2c_isa,i2c_nforce2,cx88_dvb,cx88xx,tveeprom,i2c_algo_bit,mt352,or51132,nxt200x,cx24123,lgdt330x,cx22702<br />
dvb_pll 9220 4 cx88_dvb,or51132,nxt200x,cx22702<br />
<br />
== DVB Apps ==<br />
All that we are really interested in with DVB Apps is scan and azap. I created a SlackBuild script that will create a package from the dvb apps cvs. To use the SlackBuild script, you will first need to create a temporary directory to house the relevant components and then you will need to get the sources from the dvb apps CVS. If you are new to SlackBuild scripts, check out the [[SlackBuild_Scripts]] tutorial. You will log in to the cvs with an empty password.<br />
$ mkdir ~/dvb-apps-build<br />
$ cd ~/dvb-apps-build<br />
$ cvs -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv login<br />
$ cvs -z3 -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv co dvb-apps<br />
<br />
== Udev Rules ==<br />
By default, my udev would not create the correct devices nodes, so I found these rules on a website which fixed the problem. I can not remember what site I found them on at the moment, but I will be sure to give credit to that site when I find it again. You will need to create or edit the file /etc/udev/rules.d/010_local.rules and place this information in it:<br />
#create correct dvb devices<br />
KERNEL=="dvb0.dvr*", NAME="dvb/adapter0/dvr%n"<br />
KERNEL=="dvb0.demux*", NAME="dvb/adapter0/demux%n"<br />
KERNEL=="dvb0.frontend*", NAME="dvb/adapter0/frontend%n"<br />
KERNEL=="dvb0.audio*", NAME="dvb/adapter0/audio%n"<br />
KERNEL=="dvb0.ca*", NAME="dvb/adapter0/ca%n"<br />
KERNEL=="dvb0.osd*", NAME="dvb/adapter0/osd%n"<br />
KERNEL=="dvb0.net*", NAME="dvb/adapter0/net%n"<br />
KERNEL=="dvb0.video*", NAME="dvb/adapter0/video%n"<br />
<br />
== Scanning for Channels ==<br />
Once dvb-apps is installed, you can see if everything is working correctly. First, you need to create the ~/.azap directory, then you need to create your channels.conf file. Since my ATI HDTVWonder uses an antenna to grab channels, I used the us-NTSC-center-frequencies-8VSB database file.<br />
$ mkdir ~/.azap<br />
$ touch ~/.azap/channels.conf<br />
$ scan /usr/local/share/dvb/scan/atsc/us-NTSC-center-frequencies-8VSB > ~/.azap/channels.conf<br />
This will take some time and it will give you a lot of "tuning failed" messages, but if it is successful, you will see something like this when it is done:<br />
dumping lists (12 services)<br />
WJZ-DT:617000000:8VSB:49:52:1<br />
WNUV High Def:629000000:8VSB:49:52:3<br />
WNUV - The Tube:629000000:8VSB:65:68:4<br />
Same as the Tube:629000000:8VSB:81:84:5<br />
FOX45 HDTV:665000000:8VSB:49:52:3<br />
FOX45 Digital Television:665000000:8VSB:65:68:4<br />
WMAR-Radar SD-3:701000000:8VSB:81:84:5<br />
WMAR-SD2:701000000:8VSB:65:68:4<br />
WMAR-HD:701000000:8VSB:49:52:3<br />
WMAR-TV:701000000:8VSB:0:0:65535<br />
WBALDT:743000000:8VSB:49:52:1<br />
WBALSD:743000000:8VSB:65:68:2<br />
Done.<br />
You can edit that file to remove channels as you please. If you want to use MPlayer for output, copy the channels.conf over to ~/.mplayer, and, likewise, ~/.xine for using Xine. You can substitute symlinks if you are more comfortable with that, too. Once the file is in ~/.azap, you can test the channels by running something similar to:<br />
$ azap -r WBALDT<br />
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'<br />
tuning to 743000000 Hz<br />
video pid 0x0031, audio pid 0x0034<br />
status 1f | signal 9fb0 | snr 5c32 | ber 00000000 | unc 0000007f | FE_HAS_LOCK<br />
status 1f | signal fbf0 | snr df58 | ber 00000060 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc20 | snr de9c | ber 00000008 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fb50 | snr db7c | ber 00000018 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc70 | snr dc66 | ber 00000028 | unc 00000000 | FE_HAS_LOCK<br />
Hit CTRL+C after a few lines to exit out. Those lines above show that everything is working alright. You can also check that everything is o.k. with dmesg:<br />
$ dmesg<br />
...<br />
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...<br />
nxt2004: Waiting for firmware upload(2)...<br />
nxt2004: Firmware upload complete<br />
cx88[0]/2: queue is empty - first active<br />
cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2<br />
cx88[0]/2: setting the interrupt mask<br />
cx88[0]/2: [f53b9b80/0] cx8802_buf_queue - first active<br />
cx88[0]/2: cx8802_restart_queue<br />
cx88[0]/2: cx8802_restart_queue: queue is empty<br />
<br />
== Setting up MPlayer ==<br />
According to the MPlayer website, the configuration script should detect your DVB card and compile DVB support automatically. That did not work for me. The configure script could not find my dvb include directory, so i had to specify it when I ran configure. I edited Rob Workman's SlackBuild script [[http://slackbuilds.rlworkman.net/MPlayer/]] to allow for DVB support to be compiled. Here is the configure options I used, the rest of the script was left untouched:<br />
./configure \<br />
--prefix=/usr \<br />
--confdir=/etc/mplayer \<br />
--enable-gui \<br />
--enable-menu \<br />
--enable-dvb \<br />
--with-dvbincdir=/usr/src/linux/include \<br />
--enable-xmms \<br />
--with-codecsdir=$CODECSDIR \<br />
--with-win32libdir=$CODECSDIR <br />
<br />
Notice the "--enable-dvb" and "--with-dvbincdir" options. Once I specified those, everything ran fine. Once MPlayer is compiled correctly and installed, make sure you place a copy of channels.conf in ~/.mplayer. When you are done that, you can run MPlayer by either specifying the device or by specifying the channel:<br />
$ mplayer /dev/dvb/adapter0/dvr0<br />
or<br />
$ mplayer dvb://WMARHD<br />
GMPlayer is a GTK frontend that gets installed with MPlayer and can also be used for DVB, but I have not figured out how to get a DVB option in the menus yet. When I figure it out, I will update this accordingly. Right now, you can launch gmplayer using the same lines above by simply substituting mplayer with gmplayer.<br />
<br />
== Setting up Xine ==<br />
According to everything I have read about Xine, it is supposed to compile automatically with DVB support. However, I still can not get it to view my DVB stream. As soon as I figure out how to make it work, I will update this page accordingly.<br />
<br />
== Resources ==<br />
<br />
http://www.mythtv.org/wiki/index.php/ATI_HDTV_Wonder<br />
<br />
http://www.mythtv.org/wiki/index.php/Adding_QAM_Channels_For_HDTV_Tuner_Cards<br />
<br />
http://www.mythtv.org/wiki/index.php/Dvb_Apps<br />
<br />
http://www.linuxtv.org/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=SlackBuild_Scripts&diff=900SlackBuild Scripts2014-03-15T16:31:25Z<p>Rworkman: Reverted edits by Sinyorita (talk) to last revision by Rworkman</p>
<hr />
<div>SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source. <br />
<br />
While not necessary to compile and create packages on Slackware, SlackBuilds serve as tools for scripting the compiling and packaging processes, which are often repetitive. Just as importantly, SlackBuilds also act as documentation of compile-time options and configurations for that particular package. For that reason, official Slackware packages come with SlackBuilds bundled with the source code, and the inclusion of a SlackBuild is desirable in third-party packages.<br />
<br />
== Using SlackBuild Scripts ==<br />
In this example I'm going to use the [http://www.pidgin.im Pidgin] slackbuild. First you find on the mirror in the source directory and download the whole directory of Pidgin:<br />
<br />
: <code>mkdir pidgin</code><br />
: <code>cd pidgin</code><br />
: <code>wget --passive-ftp <nowiki>ftp://slackware.at/slackware-12.1/source/xap/pidgin/*</nowiki></code><br />
<br />
This downloads the files needed for Slackware scripts. The same idea applies for SlackBuild scripts from other<br />
sources - you generally need to download all of the files in the directory that contains the build script. For example, in the pidgin source directory, you would need the following files:<br />
<br />
: <code>pidgin-2.4.1.tar.bz2 pidgin-encryption-3.0.tar.gz pidgin.SlackBuild* slack-desc </code><br />
<br />
There will sometimes be other files, such as doinst.sh, diff.gz patch files, and rc.* scripts in this directory.<br />
<br />
Now, say you want to get the newest version of pidgin? Well, you download the tar.bz2 file (in Pidgin, the script uses tar.bz2). Now you open up pidgin.Slackbuild:<br />
<br />
: <code>VERSION=2.4.1</code><br />
<br />
This is the line we are looking at. Now we can change this to<br />
<br />
: <code>VERSION=2.4.2</code><br />
<br />
Now you can edit the compile flags and other cool things not covered here. Now that we have downloaded and edited the SlackBuild script, let's make it executable:<br />
<br />
: <code>chmod +x pidgin.SlackBuild</code><br />
<br />
Now this is executable, and we want to run as root for permissions and other reasons so we want to become root:<br />
<br />
: <code>su -</code><br />
<br />
Now we start the script, and this will compile Pidgin and make a Slackware package. Depending on how the <br />
script is written, the resulting package will be in /tmp, some directory of /tmp, or perhaps some<br />
other location - have a look at the SlackBuild script for some hints if you can't find the package that<br />
was built. <br />
<br />
Once you find the package, you simply use 'installpkg' to install it normally (and you probably want to<br />
move it somewhere else on your system for safekeeping).<br />
<br />
: <code>./pidgin.SlackBuild</code><br />
<br />
=SlackBuild Archives=<br />
;* http://www.slackbuilds.org<br />
;* http://repository.slacky.eu<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
<br />
=Other Resources=<br />
For a bit more detailed tutorial, see this entry: [[Writing A SlackBuild Script]]<br />
<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=SlackBuild_Scripts&diff=896SlackBuild Scripts2014-01-20T06:55:19Z<p>Rworkman: Die in a fire, spammer.</p>
<hr />
<div>SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source. <br />
<br />
While not necessary to compile and create packages on Slackware, SlackBuilds serve as tools for scripting the compiling and packaging processes, which are often repetitive. Just as importantly, SlackBuilds also act as documentation of compile-time options and configurations for that particular package. For that reason, official Slackware packages come with SlackBuilds bundled with the source code, and the inclusion of a SlackBuild is desirable in third-party packages.<br />
<br />
== Using SlackBuild Scripts ==<br />
In this example I'm going to use the [http://www.pidgin.im Pidgin] slackbuild. First you find on the mirror in the source directory and download the whole directory of Pidgin:<br />
<br />
: <code>mkdir pidgin</code><br />
: <code>cd pidgin</code><br />
: <code>wget --passive-ftp <nowiki>ftp://slackware.at/slackware-12.1/source/xap/pidgin/*</nowiki></code><br />
<br />
This downloads the files needed for Slackware scripts. The same idea applies for SlackBuild scripts from other<br />
sources - you generally need to download all of the files in the directory that contains the build script. For example, in the pidgin source directory, you would need the following files:<br />
<br />
: <code>pidgin-2.4.1.tar.bz2 pidgin-encryption-3.0.tar.gz pidgin.SlackBuild* slack-desc </code><br />
<br />
There will sometimes be other files, such as doinst.sh, diff.gz patch files, and rc.* scripts in this directory.<br />
<br />
Now, say you want to get the newest version of pidgin? Well, you download the tar.bz2 file (in Pidgin, the script uses tar.bz2). Now you open up pidgin.Slackbuild:<br />
<br />
: <code>VERSION=2.4.1</code><br />
<br />
This is the line we are looking at. Now we can change this to<br />
<br />
: <code>VERSION=2.4.2</code><br />
<br />
Now you can edit the compile flags and other cool things not covered here. Now that we have downloaded and edited the SlackBuild script, let's make it executable:<br />
<br />
: <code>chmod +x pidgin.SlackBuild</code><br />
<br />
Now this is executable, and we want to run as root for permissions and other reasons so we want to become root:<br />
<br />
: <code>su -</code><br />
<br />
Now we start the script, and this will compile Pidgin and make a Slackware package. Depending on how the <br />
script is written, the resulting package will be in /tmp, some directory of /tmp, or perhaps some<br />
other location - have a look at the SlackBuild script for some hints if you can't find the package that<br />
was built. <br />
<br />
Once you find the package, you simply use 'installpkg' to install it normally (and you probably want to<br />
move it somewhere else on your system for safekeeping).<br />
<br />
: <code>./pidgin.SlackBuild</code><br />
<br />
=SlackBuild Archives=<br />
;* http://www.slackbuilds.org<br />
;* http://repository.slacky.eu<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
<br />
=Other Resources=<br />
For a bit more detailed tutorial, see this entry: [[Writing A SlackBuild Script]]<br />
<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=SlackBuild_Scripts&diff=895SlackBuild Scripts2014-01-20T06:52:35Z<p>Rworkman: Reverted edits by Domtheos (talk) to last revision by Kath16</p>
<hr />
<div>SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source. <br />
<br />
While not necessary to compile and create packages on Slackware, SlackBuilds serve as tools for scripting the compiling and packaging processes, which are often repetitive. Just as importantly, SlackBuilds also act as documentation of compile-time options and configurations for that particular package. For that reason, official Slackware packages come with SlackBuilds bundled with the source code, and the inclusion of a SlackBuild is desirable in third-party packages.<br />
<br />
== Using SlackBuild Scripts ==<br />
In this example I'm going to use the [http://www.pidgin.im Pidgin] slackbuild. First you find on the mirror in the source directory and download the whole directory of Pidgin:<br />
<br />
: <code>mkdir pidgin</code><br />
: <code>cd pidgin</code><br />
: <code>wget --passive-ftp <nowiki>ftp://slackware.at/slackware-12.1/source/xap/pidgin/*</nowiki></code><br />
<br />
This downloads the files needed for Slackware scripts. The same idea applies for SlackBuild scripts from other<br />
sources - you generally need to download all of the files in the directory that contains the build script. For example, in the pidgin source directory, you would need the following files:<br />
<br />
: <code>pidgin-2.4.1.tar.bz2 pidgin-encryption-3.0.tar.gz pidgin.SlackBuild* slack-desc </code><br />
<br />
There will sometimes be other files, such as doinst.sh, diff.gz patch files, and rc.* scripts in this directory.<br />
<br />
Now, say you want to get the newest version of pidgin? Well, you download the tar.bz2 file (in Pidgin, the script uses tar.bz2). Now you open up pidgin.Slackbuild:<br />
<br />
: <code>VERSION=2.4.1</code><br />
<br />
This is the line we are looking at. Now we can change this to<br />
<br />
: <code>VERSION=2.4.2</code><br />
<br />
Now you can edit the compile flags and other cool things not covered here. Now that we have downloaded and edited the SlackBuild script, let's make it executable:<br />
<br />
: <code>chmod +x pidgin.SlackBuild</code><br />
<br />
Now this is executable, and we want to run as root for permissions and other reasons so we want to become root:<br />
<br />
: <code>su -</code><br />
<br />
Now we start the script, and this will compile Pidgin and make a Slackware package. Depending on how the <br />
script is written, the resulting package will be in /tmp, some directory of /tmp, or perhaps some<br />
other location - have a look at the SlackBuild script for some hints if you can't find the package that<br />
was built. <br />
<br />
Once you find the package, you simply use 'installpkg' to install it normally (and you probably want to<br />
move it somewhere else on your system for safekeeping).<br />
<br />
: <code>./pidgin.SlackBuild</code><br />
<br />
=SlackBuild Archives=<br />
;* http://www.slackbuilds.org<br />
;* http://repository.slacky.eu<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
<br />
=Other Resources=<br />
For a bit more detailed tutorial, see this entry: [[Writing A SlackBuild Script]] [http://samsvaginalmeshlawsuitblog.wordpress.com/ Sam's Vaginal Mesh Lawsuit Blog]<br />
[http://samsvaginalmeshlawsuitblog.webs.com/ Sam's Blog]<br />
<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=DVB&diff=870DVB2013-11-21T01:11:25Z<p>Rworkman: /* DVB Apps */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
== Introduction ==<br />
I've been a big fan of tv tuner cards for almost as long as I've been in to computers. As soon as my dad bought an HDTV, I knew I had to have it, and the first chance I had was to buy the ATI HDTV Wonder card for my computer. Sure, the picture can be bad sometimes because you are grabbing the signal out of the air with an unamplified antenna, but it is well worth it. When I finally decided to make the jump to Linux a few months ago, I researched ahead of time if it was possible to use my card in Linux, and to my surprise I could. Let me note that it did take me a few months of on and off work to get it running since I was pretty much learning Linux from scratch along the way. The biggest pitfalls I ran in to was the lack of a complete HOWTO to lead me through the steps from start to finish and the lack of a large DVB/HDTV user community to ask for help when I ran in to trouble. I hope that this tutorial gets rid of those two pitfalls and lets you get your HDTV card working without any trouble.<br />
<br />
==Kernel Configuration ==<br />
I'm not sure which kernel exactly began including the necesary modules for the ATI HDTV Wonder card, but I do know that kernel versions 2.6.15 and up have them. In order to use the ATI HDTV Wonder, you need to enable the correct modules in the kernel. You need to enable I2C and the cx88 DVB modules under Device Drivers. If you are new to building your own kernel, see [[Kernel26Compilation]]<br />
<br />
snipped from my .config<br />
#<br />
# I2C support<br />
#<br />
CONFIG_I2C=m<br />
CONFIG_I2C_CHARDEV=m<br />
<br />
#<br />
# I2C Algorithms<br />
#<br />
CONFIG_I2C_ALGOBIT=m<br />
<br />
#<br />
# Video For Linux<br />
#<br />
<br />
#<br />
# Video Adapters<br />
#<br />
CONFIG_VIDEO_CX88=m<br />
CONFIG_VIDEO_CX88_ALSA=m<br />
CONFIG_VIDEO_CX88_DVB=m<br />
CONFIG_VIDEO_CX88_DVB_ALL_FRONTENDS=n<br />
CONFIG_VIDEO_CX88_VP3054=m<br />
#<br />
# Digital Video Broadcasting Devices<br />
#<br />
CONFIG_DVB=y<br />
CONFIG_DVB_CORE=m<br />
<br />
#<br />
# ATSC (North American/Korean Terresterial DTV) frontends<br />
#<br />
CONFIG_DVB_NXT200X=m<br />
<br />
If you are a less advanced user, it won't hurt anything if you select everything that might remotely deal with DVB as a Module (hit `M`). When you are done, save the configuration and compile the kernel. Before you reboot, you need to download the firmware for the card.<br />
<br />
== Firmware ==<br />
Make sure you are in /usr/src/linux<br />
# pwd<br />
/usr/src/linux<br />
There is a script provided that will download the appropriate firmware driver for you. First, make it executable, then run it.<br />
# chmod +x Documentation/dvb/get_dvb_firmware<br />
# ./Documentation/dvb/get_dvb_firmware nxt2004<br />
Then the firmware file needs to be copied to the directory where hotplug will find it. On Slackware, this directory is /lib/firmware<br />
[http://www.optimaweb.co.id/jasa-seo Jasa seo Jakarta], [http://www.optimaweb.co.id/jasa-seo Jasa seo Bergaransi]<br />
# cp dvb-fe-nxt2004.fw /lib/firmware<br />
Now you can reboot in to your new kernel, and your card should be automatically recognized. You can check to see if the modules loaded with lsmod<br />
$ lsmod | grep cx88<br />
cx88_dvb 8964 0<br />
cx8802 8068 1 cx88_dvb<br />
cx88xx 54180 2 cx88_dvb,cx8802<br />
ir_common 7812 1 cx88xx<br />
btcx_risc 3848 2 cx8802,cx88xx<br />
tveeprom 12304 1 cx88xx<br />
cx88_vp3054_i2c 3456 1 cx88_dvb<br />
i2c_algo_bit 7432 2 cx88xx,cx88_vp3054_i2c<br />
mt352 5380 1 cx88_dvb<br />
or51132 8324 1 cx88_dvb<br />
video_buf_dvb 4228 1 cx88_dvb<br />
video_buf 15364 4 cx88_dvb,cx8802,cx88xx,video_buf_dvb<br />
nxt200x 11524 1 cx88_dvb<br />
cx24123 7684 1 cx88_dvb<br />
lgdt330x 6684 1 cx88_dvb<br />
cx22702 5252 1 cx88_dvb<br />
i2c_core 15248 15 nvidia,w83627hf,eeprom,i2c_isa,i2c_nforce2,cx88_dvb,cx88xx,tveeprom,i2c_algo_bit,mt352,or51132,nxt200x,cx24123,lgdt330x,cx22702<br />
dvb_pll 9220 4 cx88_dvb,or51132,nxt200x,cx22702<br />
<br />
== DVB Apps ==<br />
All that we are really interested in with DVB Apps is scan and azap. I created a SlackBuild script that will create a package from the dvb apps cvs. To use the SlackBuild script, you will first need to create a temporary directory to house the relevant components and then you will need to get the sources from the dvb apps CVS. If you are new to SlackBuild scripts, check out the [[SlackBuild_Scripts]] tutorial. You will log in to the cvs with an empty password.<br />
$ mkdir ~/dvb-apps-build<br />
$ cd ~/dvb-apps-build<br />
$ cvs -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv login<br />
$ cvs -z3 -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv co dvb-apps<br />
<br />
== Udev Rules ==<br />
By default, my udev would not create the correct devices nodes, so I found these rules on a website which fixed the problem. I can not remember what site I found them on at the moment, but I will be sure to give credit to that site when I find it again. You will need to create or edit the file /etc/udev/rules.d/010_local.rules and place this information in it:<br />
#create correct dvb devices<br />
KERNEL=="dvb0.dvr*", NAME="dvb/adapter0/dvr%n"<br />
KERNEL=="dvb0.demux*", NAME="dvb/adapter0/demux%n"<br />
KERNEL=="dvb0.frontend*", NAME="dvb/adapter0/frontend%n"<br />
KERNEL=="dvb0.audio*", NAME="dvb/adapter0/audio%n"<br />
KERNEL=="dvb0.ca*", NAME="dvb/adapter0/ca%n"<br />
KERNEL=="dvb0.osd*", NAME="dvb/adapter0/osd%n"<br />
KERNEL=="dvb0.net*", NAME="dvb/adapter0/net%n"<br />
KERNEL=="dvb0.video*", NAME="dvb/adapter0/video%n"<br />
<br />
== Scanning for Channels ==<br />
Once dvb-apps is installed, you can see if everything is working correctly. First, you need to create the ~/.azap directory, then you need to create your channels.conf file. Since my ATI HDTVWonder uses an antenna to grab channels, I used the us-NTSC-center-frequencies-8VSB database file.<br />
$ mkdir ~/.azap<br />
$ touch ~/.azap/channels.conf<br />
$ scan /usr/local/share/dvb/scan/atsc/us-NTSC-center-frequencies-8VSB > ~/.azap/channels.conf<br />
This will take some time and it will give you a lot of "tuning failed" messages, but if it is successful, you will see something like this when it is done:<br />
dumping lists (12 services)<br />
WJZ-DT:617000000:8VSB:49:52:1<br />
WNUV High Def:629000000:8VSB:49:52:3<br />
WNUV - The Tube:629000000:8VSB:65:68:4<br />
Same as the Tube:629000000:8VSB:81:84:5<br />
FOX45 HDTV:665000000:8VSB:49:52:3<br />
FOX45 Digital Television:665000000:8VSB:65:68:4<br />
WMAR-Radar SD-3:701000000:8VSB:81:84:5<br />
WMAR-SD2:701000000:8VSB:65:68:4<br />
WMAR-HD:701000000:8VSB:49:52:3<br />
WMAR-TV:701000000:8VSB:0:0:65535<br />
WBALDT:743000000:8VSB:49:52:1<br />
WBALSD:743000000:8VSB:65:68:2<br />
Done.<br />
You can edit that file to remove channels as you please. If you want to use MPlayer for output, copy the channels.conf over to ~/.mplayer, and, likewise, ~/.xine for using Xine. You can substitute symlinks if you are more comfortable with that, too. Once the file is in ~/.azap, you can test the channels by running something similar to:<br />
$ azap -r WBALDT<br />
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'<br />
tuning to 743000000 Hz<br />
video pid 0x0031, audio pid 0x0034<br />
status 1f | signal 9fb0 | snr 5c32 | ber 00000000 | unc 0000007f | FE_HAS_LOCK<br />
status 1f | signal fbf0 | snr df58 | ber 00000060 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc20 | snr de9c | ber 00000008 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fb50 | snr db7c | ber 00000018 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc70 | snr dc66 | ber 00000028 | unc 00000000 | FE_HAS_LOCK<br />
Hit CTRL+C after a few lines to exit out. Those lines above show that everything is working alright. You can also check that everything is o.k. with dmesg:<br />
$ dmesg<br />
...<br />
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...<br />
nxt2004: Waiting for firmware upload(2)...<br />
nxt2004: Firmware upload complete<br />
cx88[0]/2: queue is empty - first active<br />
cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2<br />
cx88[0]/2: setting the interrupt mask<br />
cx88[0]/2: [f53b9b80/0] cx8802_buf_queue - first active<br />
cx88[0]/2: cx8802_restart_queue<br />
cx88[0]/2: cx8802_restart_queue: queue is empty<br />
<br />
== Setting up MPlayer ==<br />
According to the MPlayer website, the configuration script should detect your DVB card and compile DVB support automatically. That did not work for me. The configure script could not find my dvb include directory, so i had to specify it when I ran configure. I edited Rob Workman's SlackBuild script [[http://slackbuilds.rlworkman.net/MPlayer/]] to allow for DVB support to be compiled. Here is the configure options I used, the rest of the script was left untouched:<br />
./configure \<br />
--prefix=/usr \<br />
--confdir=/etc/mplayer \<br />
--enable-gui \<br />
--enable-menu \<br />
--enable-dvb \<br />
--with-dvbincdir=/usr/src/linux/include \<br />
--enable-xmms \<br />
--with-codecsdir=$CODECSDIR \<br />
--with-win32libdir=$CODECSDIR <br />
<br />
Notice the "--enable-dvb" and "--with-dvbincdir" options. Once I specified those, everything ran fine. Once MPlayer is compiled correctly and installed, make sure you place a copy of channels.conf in ~/.mplayer. When you are done that, you can run MPlayer by either specifying the device or by specifying the channel:<br />
$ mplayer /dev/dvb/adapter0/dvr0<br />
or<br />
$ mplayer dvb://WMARHD<br />
GMPlayer is a GTK frontend that gets installed with MPlayer and can also be used for DVB, but I have not figured out how to get a DVB option in the menus yet. When I figure it out, I will update this accordingly. Right now, you can launch gmplayer using the same lines above by simply substituting mplayer with gmplayer.<br />
<br />
== Setting up Xine ==<br />
According to everything I have read about Xine, it is supposed to compile automatically with DVB support. However, I still can not get it to view my DVB stream. As soon as I figure out how to make it work, I will update this page accordingly.<br />
<br />
== Resources ==<br />
<br />
http://www.mythtv.org/wiki/index.php/ATI_HDTV_Wonder<br />
<br />
http://www.mythtv.org/wiki/index.php/Adding_QAM_Channels_For_HDTV_Tuner_Cards<br />
<br />
http://www.mythtv.org/wiki/index.php/Dvb_Apps<br />
<br />
http://www.linuxtv.org/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=DVB&diff=869DVB2013-11-21T01:11:04Z<p>Rworkman: Fucking spammers</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
== Introduction ==<br />
I've been a big fan of tv tuner cards for almost as long as I've been in to computers. As soon as my dad bought an HDTV, I knew I had to have it, and the first chance I had was to buy the ATI HDTV Wonder card for my computer. Sure, the picture can be bad sometimes because you are grabbing the signal out of the air with an unamplified antenna, but it is well worth it. When I finally decided to make the jump to Linux a few months ago, I researched ahead of time if it was possible to use my card in Linux, and to my surprise I could. Let me note that it did take me a few months of on and off work to get it running since I was pretty much learning Linux from scratch along the way. The biggest pitfalls I ran in to was the lack of a complete HOWTO to lead me through the steps from start to finish and the lack of a large DVB/HDTV user community to ask for help when I ran in to trouble. I hope that this tutorial gets rid of those two pitfalls and lets you get your HDTV card working without any trouble.<br />
<br />
==Kernel Configuration ==<br />
I'm not sure which kernel exactly began including the necesary modules for the ATI HDTV Wonder card, but I do know that kernel versions 2.6.15 and up have them. In order to use the ATI HDTV Wonder, you need to enable the correct modules in the kernel. You need to enable I2C and the cx88 DVB modules under Device Drivers. If you are new to building your own kernel, see [[Kernel26Compilation]]<br />
<br />
snipped from my .config<br />
#<br />
# I2C support<br />
#<br />
CONFIG_I2C=m<br />
CONFIG_I2C_CHARDEV=m<br />
<br />
#<br />
# I2C Algorithms<br />
#<br />
CONFIG_I2C_ALGOBIT=m<br />
<br />
#<br />
# Video For Linux<br />
#<br />
<br />
#<br />
# Video Adapters<br />
#<br />
CONFIG_VIDEO_CX88=m<br />
CONFIG_VIDEO_CX88_ALSA=m<br />
CONFIG_VIDEO_CX88_DVB=m<br />
CONFIG_VIDEO_CX88_DVB_ALL_FRONTENDS=n<br />
CONFIG_VIDEO_CX88_VP3054=m<br />
#<br />
# Digital Video Broadcasting Devices<br />
#<br />
CONFIG_DVB=y<br />
CONFIG_DVB_CORE=m<br />
<br />
#<br />
# ATSC (North American/Korean Terresterial DTV) frontends<br />
#<br />
CONFIG_DVB_NXT200X=m<br />
<br />
If you are a less advanced user, it won't hurt anything if you select everything that might remotely deal with DVB as a Module (hit `M`). When you are done, save the configuration and compile the kernel. Before you reboot, you need to download the firmware for the card.<br />
<br />
== Firmware ==<br />
Make sure you are in /usr/src/linux<br />
# pwd<br />
/usr/src/linux<br />
There is a script provided that will download the appropriate firmware driver for you. First, make it executable, then run it.<br />
# chmod +x Documentation/dvb/get_dvb_firmware<br />
# ./Documentation/dvb/get_dvb_firmware nxt2004<br />
Then the firmware file needs to be copied to the directory where hotplug will find it. On Slackware, this directory is /lib/firmware<br />
[http://www.optimaweb.co.id/jasa-seo Jasa seo Jakarta], [http://www.optimaweb.co.id/jasa-seo Jasa seo Bergaransi]<br />
# cp dvb-fe-nxt2004.fw /lib/firmware<br />
Now you can reboot in to your new kernel, and your card should be automatically recognized. You can check to see if the modules loaded with lsmod<br />
$ lsmod | grep cx88<br />
cx88_dvb 8964 0<br />
cx8802 8068 1 cx88_dvb<br />
cx88xx 54180 2 cx88_dvb,cx8802<br />
ir_common 7812 1 cx88xx<br />
btcx_risc 3848 2 cx8802,cx88xx<br />
tveeprom 12304 1 cx88xx<br />
cx88_vp3054_i2c 3456 1 cx88_dvb<br />
i2c_algo_bit 7432 2 cx88xx,cx88_vp3054_i2c<br />
mt352 5380 1 cx88_dvb<br />
or51132 8324 1 cx88_dvb<br />
video_buf_dvb 4228 1 cx88_dvb<br />
video_buf 15364 4 cx88_dvb,cx8802,cx88xx,video_buf_dvb<br />
nxt200x 11524 1 cx88_dvb<br />
cx24123 7684 1 cx88_dvb<br />
lgdt330x 6684 1 cx88_dvb<br />
cx22702 5252 1 cx88_dvb<br />
i2c_core 15248 15 nvidia,w83627hf,eeprom,i2c_isa,i2c_nforce2,cx88_dvb,cx88xx,tveeprom,i2c_algo_bit,mt352,or51132,nxt200x,cx24123,lgdt330x,cx22702<br />
dvb_pll 9220 4 cx88_dvb,or51132,nxt200x,cx22702<br />
<br />
== DVB Apps ==<br />
All that we are really interested in with DVB Apps is scan and azap. I created a SlackBuild script that will create a package from the dvb apps cvs. To use the SlackBuild script, you will first need to create a temporary directory to house the relevant components and then you will need to get the sources from the dvb apps CVS. If you are new to SlackBuild scripts, check out the [[SlackBuild_Scripts]] tutorial. You will log in to the cvs with an empty password.<br />
$ mkdir ~/dvb-apps-build<br />
$ cd ~/dvb-apps-build<br />
$ cvs -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv login<br />
$ cvs -z3 -d :pserver:anonymous@cvs.linuxtv.org:/cvs/linuxtv co dvb-apps<br />
Eventually, my SlackBuild will be hosted here http://slackbuilds.rlworkman.net/CONTRIB/linuxtv-dvb-apps/ (thanks to robw810).<br />
<br />
== Udev Rules ==<br />
By default, my udev would not create the correct devices nodes, so I found these rules on a website which fixed the problem. I can not remember what site I found them on at the moment, but I will be sure to give credit to that site when I find it again. You will need to create or edit the file /etc/udev/rules.d/010_local.rules and place this information in it:<br />
#create correct dvb devices<br />
KERNEL=="dvb0.dvr*", NAME="dvb/adapter0/dvr%n"<br />
KERNEL=="dvb0.demux*", NAME="dvb/adapter0/demux%n"<br />
KERNEL=="dvb0.frontend*", NAME="dvb/adapter0/frontend%n"<br />
KERNEL=="dvb0.audio*", NAME="dvb/adapter0/audio%n"<br />
KERNEL=="dvb0.ca*", NAME="dvb/adapter0/ca%n"<br />
KERNEL=="dvb0.osd*", NAME="dvb/adapter0/osd%n"<br />
KERNEL=="dvb0.net*", NAME="dvb/adapter0/net%n"<br />
KERNEL=="dvb0.video*", NAME="dvb/adapter0/video%n"<br />
<br />
== Scanning for Channels ==<br />
Once dvb-apps is installed, you can see if everything is working correctly. First, you need to create the ~/.azap directory, then you need to create your channels.conf file. Since my ATI HDTVWonder uses an antenna to grab channels, I used the us-NTSC-center-frequencies-8VSB database file.<br />
$ mkdir ~/.azap<br />
$ touch ~/.azap/channels.conf<br />
$ scan /usr/local/share/dvb/scan/atsc/us-NTSC-center-frequencies-8VSB > ~/.azap/channels.conf<br />
This will take some time and it will give you a lot of "tuning failed" messages, but if it is successful, you will see something like this when it is done:<br />
dumping lists (12 services)<br />
WJZ-DT:617000000:8VSB:49:52:1<br />
WNUV High Def:629000000:8VSB:49:52:3<br />
WNUV - The Tube:629000000:8VSB:65:68:4<br />
Same as the Tube:629000000:8VSB:81:84:5<br />
FOX45 HDTV:665000000:8VSB:49:52:3<br />
FOX45 Digital Television:665000000:8VSB:65:68:4<br />
WMAR-Radar SD-3:701000000:8VSB:81:84:5<br />
WMAR-SD2:701000000:8VSB:65:68:4<br />
WMAR-HD:701000000:8VSB:49:52:3<br />
WMAR-TV:701000000:8VSB:0:0:65535<br />
WBALDT:743000000:8VSB:49:52:1<br />
WBALSD:743000000:8VSB:65:68:2<br />
Done.<br />
You can edit that file to remove channels as you please. If you want to use MPlayer for output, copy the channels.conf over to ~/.mplayer, and, likewise, ~/.xine for using Xine. You can substitute symlinks if you are more comfortable with that, too. Once the file is in ~/.azap, you can test the channels by running something similar to:<br />
$ azap -r WBALDT<br />
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'<br />
tuning to 743000000 Hz<br />
video pid 0x0031, audio pid 0x0034<br />
status 1f | signal 9fb0 | snr 5c32 | ber 00000000 | unc 0000007f | FE_HAS_LOCK<br />
status 1f | signal fbf0 | snr df58 | ber 00000060 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc20 | snr de9c | ber 00000008 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fb50 | snr db7c | ber 00000018 | unc 00000000 | FE_HAS_LOCK<br />
status 1f | signal fc70 | snr dc66 | ber 00000028 | unc 00000000 | FE_HAS_LOCK<br />
Hit CTRL+C after a few lines to exit out. Those lines above show that everything is working alright. You can also check that everything is o.k. with dmesg:<br />
$ dmesg<br />
...<br />
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...<br />
nxt2004: Waiting for firmware upload(2)...<br />
nxt2004: Firmware upload complete<br />
cx88[0]/2: queue is empty - first active<br />
cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2<br />
cx88[0]/2: setting the interrupt mask<br />
cx88[0]/2: [f53b9b80/0] cx8802_buf_queue - first active<br />
cx88[0]/2: cx8802_restart_queue<br />
cx88[0]/2: cx8802_restart_queue: queue is empty<br />
<br />
== Setting up MPlayer ==<br />
According to the MPlayer website, the configuration script should detect your DVB card and compile DVB support automatically. That did not work for me. The configure script could not find my dvb include directory, so i had to specify it when I ran configure. I edited Rob Workman's SlackBuild script [[http://slackbuilds.rlworkman.net/MPlayer/]] to allow for DVB support to be compiled. Here is the configure options I used, the rest of the script was left untouched:<br />
./configure \<br />
--prefix=/usr \<br />
--confdir=/etc/mplayer \<br />
--enable-gui \<br />
--enable-menu \<br />
--enable-dvb \<br />
--with-dvbincdir=/usr/src/linux/include \<br />
--enable-xmms \<br />
--with-codecsdir=$CODECSDIR \<br />
--with-win32libdir=$CODECSDIR <br />
<br />
Notice the "--enable-dvb" and "--with-dvbincdir" options. Once I specified those, everything ran fine. Once MPlayer is compiled correctly and installed, make sure you place a copy of channels.conf in ~/.mplayer. When you are done that, you can run MPlayer by either specifying the device or by specifying the channel:<br />
$ mplayer /dev/dvb/adapter0/dvr0<br />
or<br />
$ mplayer dvb://WMARHD<br />
GMPlayer is a GTK frontend that gets installed with MPlayer and can also be used for DVB, but I have not figured out how to get a DVB option in the menus yet. When I figure it out, I will update this accordingly. Right now, you can launch gmplayer using the same lines above by simply substituting mplayer with gmplayer.<br />
<br />
== Setting up Xine ==<br />
According to everything I have read about Xine, it is supposed to compile automatically with DVB support. However, I still can not get it to view my DVB stream. As soon as I figure out how to make it work, I will update this page accordingly.<br />
<br />
== Resources ==<br />
<br />
http://www.mythtv.org/wiki/index.php/ATI_HDTV_Wonder<br />
<br />
http://www.mythtv.org/wiki/index.php/Adding_QAM_Channels_For_HDTV_Tuner_Cards<br />
<br />
http://www.mythtv.org/wiki/index.php/Dvb_Apps<br />
<br />
http://www.linuxtv.org/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=User_talk:Beder&diff=820User talk:Beder2013-01-02T02:27:45Z<p>Rworkman: Thanks!</p>
<hr />
<div>Thanks for the fix in Resource_Limits :-) --rworkman</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Packages&diff=577Packages2011-12-09T14:13:34Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Grissiom</p>
<hr />
<div>Slackware's package management system utilizes .tgz/.txz tarballs as its standard package format. These tarballs are tar.gz/tar.xz archives which contain Slackware built binaries, support files, a description file and installation script. Although they can be unzipped and untarred like a normal archive, they are (usually) binary-only packages intended to be installed through Slackware's provided package management tools.<br />
<br />
Information about a package is stored in two ways, in the filename of the package and a description file inside that package.<br />
<br />
==Package Tools==<br />
See the respective manual pages for more information on each of the following commands.<br />
<br />
<code>pkgtool</code><br />
<br />
<code>installpkg</code><br />
<br />
<code>removepkg</code><br />
<br />
<code>explodepkg</code><br />
<br />
<code>makepkg</code><br />
<br />
<code>upgradepkg</code><br />
<br />
==Slackware Package Layout==<br />
A typical Slackware package is laid out as such:<br />
./<br />
./install/doinst.sh<br />
./install/slack-desc<br />
[./usr/bin]<br />
[./usr/lib]<br />
[...]<br />
<br />
The install directory as well as the files within it will be deleted after the installation of the package to the root install directory (usually '/'). The install directory is not necessarily required for the most basic packages but allows additional functionality: [[slack-desc]] contains the package description, and [[doinst.sh]] contains post-installation instructions such as creating symbolic links.<br />
<br />
Every other file within the package is simply untarred (extracted) to the root directory. Most of these files are in standard locations. <br />
<br />
There are other special files within packages: <br />
<br />
'''usr/doc/<appname><version>'''<br />
All documentation included with the package (such as README, INSTALL, ChangeLog, docs/, etcetera) should be placed in this directory. Some of the files in this directory should be manually copied from the source archive, since Makefiles usually don't copy these documentation files to the package build tree.<br />
<br />
==Making Slackware Packages==<br />
See [[Building A Package]]<br />
<br />
[[Category: Information]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Log_Correlation&diff=576Log Correlation2011-12-09T14:13:32Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
'''Log Correlation'''<br />
<br />
I thought I'd talk about the importance of log correlation. For instance, you've found that someone is continually pinging your server. You want to see if your box is responding to the pings. Usually, you'll know right off, since most people know if their firewall was configured to block pings...I'm just using pings as a quick example, though. Log correlation usually consists of checking, for instance, web server logs against firewall logs, or Snort logs against firewall and web server logs. This helps you understand what suspicious activity is actually doing and if your server/workstation responded (and how it responded, if it did).<br />
<br />
I run Snort on a server, along with a web server, which is firewalled with IPTables. I have Snort report what it sees to a MySQL database, although it does record captures to a PCAP file locally. I also run Modsecurity, an application firewall that is designed to sniff and possibly block traffic going to/from web servers, mainly Apache. So, I've a ton of logs that I can correlate: Snort, Apache, IPTables, and Modsecurity logs.<br />
<br />
We'll pick something easy. In fact, I'll fabricate some logs by generating some false alerts. I'll use 'wget', to visit my website. Keep in mind that what you see below gives you the advantage...you know what you're doing and looking for when we soon check the logs. This won't be the case when some stranger or worm hits your firewall or web server (or any other application server).<br />
<br />
-bash-2.05b$ wget wigglit.ath.cx/root.exe<br />
--23:24:05-- http://wigglit.ath.cx/root.exe<br />
=> `root.exe'<br />
Resolving wigglit.ath.cx... 66.160.141.30<br />
Connecting to wigglit.ath.cx|66.160.141.30|:80... connected.<br />
HTTP request sent, awaiting response... 404 Not Found<br />
23:24:06 ERROR 404: Not Found.<br />
<br />
-bash-2.05b$ <br />
<br />
I used root.exe because there is an old vulnerability was was used to exploit flaws in IIS...the CodeRed worm of old. Now, let's check the web server's logs. I've tail'd my logs:<br />
<br />
root@starchild:/var/log/apache# tail -f -n 100 access_log<br />
12.123.12.123 - - [15/Sep/2007:23:34:35 -0400] "GET /root.exe HTTP/1.0" 404 202<br />
12.123.12.123 - - [15/Sep/2007:23:34:35 -0400] "GET /root.exe HTTP/1.0" 404 202 "-" "Wget/1.10.2"<br />
<br />
You see that the communcation was accepted. A 404 code, which means 'page not found', was generated. This is usually a good indication, as the server didn't respond favorably to the attack.<br />
<br />
Now, let us check the firewall logs. We already know that the firewall allowed the traffic, since the web server responded with a 404...if the traffic was being blocked, there would be no record of the attack in the logs, because the firewall would have intercepted the traffic before it reached the web server. We're checking the firewall logs just to be sure this guy hasn't done anything else that the web server didn't see:<br />
<br />
Sep 12 17:28:34 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=34557 DF PROTO=TCP SPT=46656 DPT=10083 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:28:44 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=18168 DF PROTO=TCP SPT=40091 DPT=449 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:28:44 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=27053 DF PROTO=TCP SPT=36295 DPT=5060 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:28:54 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=29291 DF PROTO=TCP SPT=47590 DPT=342 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:28:54 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=11788 DF PROTO=TCP SPT=43604 DPT=1519 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:04 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=17600 DF PROTO=TCP SPT=32783 DPT=577 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:04 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=51338 DF PROTO=TCP SPT=47879 DPT=18187 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:14 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=58520 DF PROTO=TCP SPT=41983 DPT=517 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:14 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=20255 DF PROTO=TCP SPT=53355 DPT=1986 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:24 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=28213 DF PROTO=TCP SPT=38543 DPT=978 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:24 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=10244 DF PROTO=TCP SPT=45624 DPT=11371 WINDOW=5840 RES=0x00 SYN URGP=0<br />
Sep 12 17:29:37 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=28 TOS=0x00 PREC=0x00 TTL=42 ID=53002 PROTO=ICMP TYPE=8 CODE=0 ID=10683 SEQ=16615<br />
Sep 15 23:21:08 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=40988 PROTO=ICMP TYPE=8 CODE=0 ID=614 SEQ=0<br />
<br />
Quite a bit of stuff, huh? This looks to be a port scan! This is something that we didn't see in the Apache logs! Good thing we checked! Looks like this IP needs to be blocked with IPTables (which we won't do in this exercise).<br />
<br />
Sadly, nothing shows in the Modsecurity logs, but we've enough information already. What about Snort? Because I've PCAP files, the search becomes a bit more involved. I'll spare the intimate details, but this is what we see:<br />
<br />
[**] [1:1256:9] WEB-IIS CodeRed v2 root.exe access [**]<br />
[Classification: Web Application Attack] [Priority: 1]<br />
09/15-23:34:35.708546 0:C:DB:F5:90:0 -> FE:FD:40:3E:E7:DC type:0x800 len:0xB0<br />
12.123.12.123:52753 -> 66.160.141.30:80 TCP TTL:56 TOS:0x0 ID:51589 IpLen:20 DgmLen:162 DF<br />
***AP*** Seq: 0xAF32BB68 Ack: 0x3F319F7A Win: 0xFFFF TcpLen: 32<br />
TCP Options (3) => NOP NOP TS: 288652007 1521931210<br />
[Xref => http://www.cert.org/advisories/CA-2001-19.html]<br />
<br />
23:34:35.708546 00:0c:db:f5:90:00 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 176: IP (tos 0x0, ttl 56, id 51589, offset 0, flags [DF], length: 162) 12.123.12.123.52753 > 66.160.141.30.80: P [tcp sum ok] 2939337576:2939337686(110) ack 1060216698 win 65535<br />
0x0000: fefd 403e e7dc 000c dbf5 9000 0800 4500 ..@>..........E.<br />
0x0010: 00a2 c985 4000 3806 56c0 47b2 0aa0 42a0 ....@.8.V.G...B.<br />
0x0020: 8d1e ce11 0050 af32 bb68 3f31 9f7a 8018 .....P.2.h?1.z..<br />
0x0030: ffff e9c5 0000 0101 080a 1134 7ae7 5ab6 ...........4z.Z.<br />
0x0040: d3ca 4745 5420 2f72 6f6f 742e 6578 6520 ..GET./root.exe.<br />
0x0050: 4854 5450 2f31 2e30 0d0a 5573 6572 2d41 HTTP/1.0..User-A<br />
0x0060: 6765 6e74 3a20 5767 6574 2f31 2e31 302e gent:.Wget/1.10.<br />
0x0070: 320d 0a41 6363 6570 743a 202a 2f2a 0d0a 2..Accept:.*/*..<br />
0x0080: 486f 7374 3a20 7769 6767 6c69 742e 6174 Host:.wigglit.at<br />
0x0090: 682e 6378 0d0a 436f 6e6e 6563 7469 6f6e h.cx..Connection<br />
0x00a0: 3a20 4b65 6570 2d41 6c69 7665 0d0a 0d0a :.Keep-Alive....<br />
<br />
The first is the Snort alert file...this is a fast alert, with minimal detail (no packet capture). The second section is the full alert, including packet capture. It is also garbled (due to the hex code and the fact that this blog has issues with formatting) Note that my logs show no response. Apparently, my Snort install doesn't have a 404 signature. Again, the fact that we can correlate helps me when my Snort install lacks the data that I may have needed. I was able to look at the Apache logs to see the 404 when my Snort logs didn't show the return traffic.<br />
<br />
Well, this concludes our chat about correlating existing logs. Note that any log files can be correlated. Correlation can also assist in tracking down network issues or issues with, for instance, a faulty Snort install (ahem). Although this discussion focused more on security, hopefully this helps someone understand their network or software architecture also.<br />
<br />
This page is also linked at [http://slackfiles.blogspot.com/2007/09/log-correlation.html my blog]<br />
<br />
--[[User:Unixfool|Ron]] 00:35, 16 September 2007 (EDT)</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Apache-cgi&diff=575Apache-cgi2011-12-09T14:13:30Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>[[Category:Tips]]<br />
<br />
==To enable a cgi directory for each user==<br />
<br />
In order to give each user their own cgi-bin directory, edit the:<br />
<br />
:Apache1 (Slackware pre-12.0): <code>/etc/httpd/httpd.conf</code> file<br><br />
:Apache2 (Slackware 12.0+): <code>/etc/httpd/extra/httpd-users.conf</code> file<br><br />
<br />
::...and add:<br />
<br />
:<code><Directory /home/*/public_html/cgi-bin/></code><br />
:<code>Options ExecCGI</code><br />
:<code>SetHandler cgi-script</code><br />
:<code></Directory></code><br />
<br />
Then, presuming that UserDir is set to public_html, a cgi program example.cgi could be loaded from that directory as:<br />
<br />
::<code>http&#58;//example.com/~rbowen/cgi-bin/example.cgi</code><br />
<br />
<br />
==To enable a cgi directory for each virtual host==<br />
<br />
In the Virtual Host section of your apache config file (<code>/etc/apache/httpd.conf</code>) add the <code>ScriptAlias</code> line below.<br />
<br />
:<code><VirtualHost *:80></code><br />
:::<code>ServerName www.''MyDomain''.org</code><br />
:::<code>DocumentRoot /home/''MyDomain''/public_html</code><br />
:::<code>ErrorLog /var/log/''MyDomain''/error.log</code><br />
:::<code><b>ScriptAlias /cgi-bin/ "/home/''MyDomain''/public_html/cgi-bin/"</b></code><br />
:<code></VirtualHost></code></div>Rworkmanhttps://www.slackwiki.com/index.php?title=Mount_Count&diff=574Mount Count2011-12-09T14:13:29Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>[[Category:Information]]<br />
A count of how many times a filesystem has been mounted. Used to determine whether a [[Forced Fsck]] should be executed.<br />
<br />
After a successful fsck (filesystem check), the mount count is reset to zero. When the mount count reaches (or exceeds) the [[Maximum Mount Count]], a Forced Fsck is executed during boot.</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Writing_A_SlackBuild_Script&diff=573Writing A SlackBuild Script2011-12-09T14:13:27Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by SiegeX</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
= Introduction =<br />
<br />
Originally written by Florian Mueller jjdm@jjdm.org<br />
Substantial cleanup and enhancement by Robby Workman (rworkman)<br />
<br />
If you use slackware as your main operating system, you have probably wanted to install quite a few applications which are not available in the official slackware.com or even third-party repositories like linuxpackages.net, or perhaps you just don't like using third-party packages. In this situation, you have several options on how to install the application:<br />
<br />
* ./configure && make && make install<br />
* use checkinstall<br />
* use installwatch<br />
* compile and use makepkg by hand<br />
* write a SlackBuild script<br />
<br />
I will go through the last option: writing [[SlackBuild Scripts]] (which combines the best qualities of all the other aforementioned methods). With a SlackBuild script, you have the build process automated, which will allow you to easily do later upgrades or patches to the package. SlackBuild scripts are also the method by which Patrick Volkerding builds all of the official packages for Slackware. If you look at the various scripts from different sources, you will notice that there is generally an application-independent portion of a script and an application-specific portion of the script.<br />
<br />
I cannot teach you how to build the "perfect" package, as reaching that goal requires fairly in-depth knowledge of the Slackware operating system. You must consider the interactions of your proposed package with all of the other packages within the distribution; they must be integrated seamlessly. What I can teach you is how to build a package that works and which stays true to the "Slackware Way."<br />
<br />
"But it takes so much time!"<br />
<br />
It will take approximately thirty minutes to go through this tutorial and about fifteen minutes to create each package (actual compile process not included), but the time you save in the future (you want to create a newer version of the package) makes the initial time expenditure worth it.<br />
<br />
= The Slackware package structure =<br />
<br />
See [[Packages#Slackware Package Layout]]<br />
<br />
= Setting up your build environment =<br />
<br />
See [[Build_Environment]] for examples of how various users do this.<br />
<br />
= Getting Started =<br />
<br />
Hopefully, everything is now clear about Slackware package structure, and you have set up a clean build environment, so we'll begin the process of building a package with a SlackBuild script.<br />
<br />
For this example, we'll create a package of latex2html - I made my homepage with that tool.<br />
<br />
First, you have to create a directory named <build_environment>/latex2html/. Get the most recent source code release of latex2html place it in this directory. Note that use of wget below to obtain the most recent source code is optional - you can just as well use your favorite web browser to download it, and then move it into the correct directory.<br />
<br />
$ cd <build_environment><br />
$ mkdir latex2html<br />
$ cd latex2html<br />
$ wget http://saftsack.fs.uni-bayreuth.de/~latex2ht/current/latex2html-2002-2-1.tar.gz # 05.02.2005<br />
<br />
Next, we'll create some other needed files with touch. If you're not familiar with touch, see:<br />
man touch<br />
Note that the *.SlackBuild file will always contain the name of the application for which it's written; for example, gaim would have gaim.SlackBuild.<br />
<br />
$ touch latex2html.SlackBuild<br />
$ touch slack-desc<br />
<br />
Extract the source code of the application, because we'll need to look at the configure script later on to determine what options we need to pass to it.<br />
<br />
$ tar -xzf latex2html-2002-2-1.tar.gz || exit 1<br />
<br />
= Writing the slack-desc file =<br />
<br />
See this [[Slack-desc]] page on SlackWiki.org for instructions on how to write a proper slack-desc file.<br />
<br />
= Writing the SlackBuild script =<br />
<br />
This is the section which takes the most time, and I'll go through it with you step by step. When you build more packages, you'll probably be able to just copy an existing SlackBuild script and customize it. First, you need to understand that you can write your SlackBuild script in any manner you choose so long as it creates a working package; the method described here is more or less the way Pat Volkerding [[http://slackware.com/~volkerdi]] does it, but even Pat has several different styles for writing the official SlackBuild scripts. Therefore, if you see something you would do a different way, feel free to do it that way - it's okay.<br />
<br />
===Initial Setup===<br />
<br />
Open the file latex2html.SlackBuild with your favourite editor. What follows below is a piece by piece walk-through of a working SlackBuild script. You may certainly paste the exact contents of those pieces, but in the author's opinion, you have a better chance of understanding it if you write everything yourself.<br />
<br />
First, you'll need to set your shell interpreter. This should be /bin/sh, as *every* Slackware system is guaranteed to have this shell installed, and you want maximum portability. For this same reason, be careful not to use any extensions and/or syntax that is customized for your particular shell (bash, zsh, or whatever), as it won't be interpreted correctly. The '-e' flag tells the shell to exit on any error; this helps with both debugging your script as well as ensuring your script does not proceed in an unknown state.<br />
<br />
#!/bin/sh -e<br />
<br />
You might want to include a license of some sort with your SlackBuild script (preferably a GPL or BSD-style license), but at a minimum, you'll want something like this:<br />
<br />
#<your name> revision date yyyy/mm/dd<br />
<br />
With the next few lines, we set some variables that will be used throughout the script. First is the "CWD" variable; in our case, CWD will be <build_environment>/latex2html/. We also test if the TMP variable is set, and if not, we set it to /tmp.<br />
<br />
#Set initial variables: <br />
<br />
CWD=$(pwd)<br />
if [ "$TMP" = "" ]; then<br />
TMP=/tmp<br />
fi<br />
<br />
Some people like to build in a subdirectory of /tmp (such as /tmp/build), but that's up to you.<br />
<br />
# The version which appears in the application's filename<br />
VERSION=2002-2-1 <br />
<br />
# If the version conflicts with the Slackware package standard<br />
# The dash character ("-") is not allowed in the VERSION string<br />
# You can set the PKG_VERSION to something else than VERSION<br />
PKG_VERSION=2002.2.1 # the version which appears in the package name. <br />
<br />
ARCH=${ARCH:-i486} # the architecture on which you want to build your package <br />
<br />
# First digit is the build number, which specifies how many times it has been built. <br />
# Second string is the short form of the authors name, typical three initials:w<br />
BUILD=${BUILD:-1_rlw}<br />
<br />
# The application's name<br />
APP=latex2html<br />
<br />
# The installation directory of the package (where its actual directory<br />
# structure will be created) <br />
PKG=$TMP/package-$APP<br />
<br />
Set SLKCFLAGS (which will be used for both CFLAGS and CXXFLAGS). If you are building on a system with an earlier version of gcc than 3.4.x, then you'll need to use "-mcpu" instead of "-mtune" below.<br />
<br />
if [ "$ARCH" = "i486" ]; then<br />
SLKCFLAGS="-O2 -march=i486 -mtune=i686"<br />
elif [ "$ARCH" = "x86_64" ]; then<br />
SLKCFLAGS="-O2 -fPIC"<br />
fi<br />
<br />
The section just finished sets up a few application-specific variables. When you want to create a package of some other application, you can usually just change the variables, and most of the further steps will work automatically.<br />
<br />
=== Extract Sources ===<br />
<br />
# Delete the leftover directories if they exist (due to a previous build)<br />
# and (re)create the packaging directory<br />
rm -rf $PKG <br />
mkdir -p $TMP $PKG<br />
rm -rf $TMP/$APP-$VERSION<br />
<br />
# Change to the TMP directory<br />
cd $TMP || exit 1<br />
<br />
# Extract the application source in TMP<br />
# Note: if your application comes as a tar.bz2, you need tar -jxvf<br />
tar -zxvf $CWD/$APP-$VERSION.tar.gz || exit 1<br />
<br />
# Change to the application source directory<br />
cd $APP-$VERSION || exit 1<br />
<br />
# Change ownership and permissions if necessary<br />
# This may not be needed in some source tarballs, but it never hurts<br />
chown -R root:root .<br />
chmod -R u+w,go+r-w,a-s .<br />
<br />
===Configure and Compile Sources===<br />
<br />
# Set configure options<br />
# If your app is written in C++, you'll also need to add a line for CXXFLAGS<br />
CFLAGS="$SLKCFLAGS" \<br />
./configure \<br />
--prefix=/usr \<br />
--sysconfdir=/etc \<br />
--localstatedir=/var \<br />
--with-perl=/usr/bin/perl \<br />
--enable-eps \<br />
--enable-gif \<br />
--enable-png \<br />
--build=$ARCH-slackware-linux \<br />
--host=$ARCH-slackware-linux <br />
<br />
# compile the source, but exit if anything goes wrong<br />
make || exit<br />
<br />
# Install everything into the package directory, but exit if anything goes wrong<br />
make install DESTDIR=$PKG || exit<br />
<br />
There are three configure options I always set:<br />
<br />
* --prefix=/usr<br />
* --sysconfdir=/etc<br />
* --localstatedir=/var<br />
<br />
This makes configuration files go to /etc, state files (such as log files) go to /var, and the rest goes to /usr. That's the usual Slackware way, but it's your system, so you can certainly install everything in /usr/local or some other location. See the Unix Filesystem Hierarchy Standard [[http://www.pathname.com/fhs/]] for more information on "correct" locations of various filetypes.<br />
<br />
You notice that there were several other options passed to the configure script, and for each application you compile, you have to figure those out for yourself - that's why you were told to extract the sources earlier in this process. You simply cd into the source directory and run:<br />
./configure --help<br />
This will produce a page or two (sometimes more, though) of information about various options that are specific to the application. Read through this information and figure out what you need (I like to pipe that command through lpr to get a printed copy, but you can certainly use some sort of pager as well:<br />
./configure --help | lpr<br />
./configure --help | less<br />
<br />
The DESTDIR variable is very important in this script because it specifies the directory in which the files should be installed. This should always be our package directory ($PKG). Unfortunately, some applications' Makefiles will not support the DESTDIR variable, so you can't use it for those apps. A simple line like this:<br />
grep DESTDIR Makefile*<br />
while inside the source directory should tell you whether it supports DESTDIR or not. If you get some lines of output with $DESTDIR in them, you're in good shape. If the command returns no output, then the Makefile does not support the DESTDIR variable.<br />
<br />
Here's a piece of advice: ALWAYS go through the ./configure && make && make install DESTDIR=/somedir process manually and as a NORMAL USER account BEFORE you run your SlackBuild script. There are quite a few applications out there which try to do "funny stuff" during the installation phase.<br />
For example, apcupsd will attempt to patch your /etc/rc.d/rc.6 init script<br />
Yes, it's possible to avoid this with a configure option, but it's not obvious that you would need<br />
to do so until you look at all of the Makefiles for apcupsd (or watch the install process)<br />
Anyway, if you go through the process as a normal user, you will get "Permission Denied" errors and such if the install process tries to write anywhere it's not allowed to do so.<br />
<br />
=== Install Documentation ===<br />
<br />
# Create a directory for documentation<br />
mkdir -p $PKG/usr/doc/$APP-$VERSION<br />
<br />
# Copy documentation to the docs directory and fix permissions<br />
cp -a BUGS Changes FAQ INSTALL LICENSE MANIFEST README TODO docs/ $PKG/usr/doc/$APP-$VERSION<br />
find $PKG/usr/doc/$APP-$VERSION -type f -exec chmod 644 {} \;<br />
<br />
I (rworkman) also like to place a copy of my SlackBuild script in this directory<br />
cat $CWD/$APP.SlackBuild > $PKG/usr/doc/$APP-$VERSION/$APP.SlackBuild<br />
<br />
Make sure you look inside the actual source archive of the application, because some applications won't have all of the documentation files specified above, and some applications will have additional files. In other words, don't just copy/paste what you see above into your SlackBuild script - you *must* customize this section for each individual application.<br />
<br />
=== Final Touches ===<br />
<br />
# Create the ./install directory and copy the slack-desc into it<br />
mkdir -p $PKG/install<br />
cat $CWD/slack-desc > $PKG/install/slack-desc<br />
<br />
NOTE: In some cases, you will have some sort of command or setup that<br />
needs to run after the package contents are installed - for this, you<br />
would add a file to $CWD called "doinst.sh" which contains the needed<br />
commands, and then compress that file with gzip. The SlackBuild script<br />
will zcat (which means to gunzip and cat its contents) that file and <br />
write the output to a doinst.sh file in the $PKG/install directory.<br />
<br />
# Add doinst.sh to package (if it exists)<br />
if [ -e $CWD/doinst.sh.gz ]; then<br />
zcat $CWD/doinst.sh.gz > $PKG/install/doinst.sh<br />
fi<br />
<br />
Let's conserve space if we can; strip libraries and binaries and compress man pages with gzip<br />
Note that you might be able to use "make install-strip" instead of "make install" above instead to accomplish the same purpose<br />
<br />
# Strip some libraries and binaries<br />
( cd $PKG<br />
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null<br />
)<br />
<br />
# Compress man pages if they exist<br />
if [ -d $PKG/usr/man ]; then<br />
( cd $PKG/usr/man<br />
find . -type f -exec gzip -9 {} \;<br />
for i in $(find . -type l) ; do ln -s $(readlink $i).gz $i.gz ; rm $i ; done<br />
) <br />
fi<br />
<br />
# Compress info pages if they exist (and remove the dir file)<br />
if [ -d $PKG/usr/info ]; then<br />
gzip -9 $PKG/usr/info/*.info<br />
rm -f $PKG/usr/info/dir<br />
fi<br />
<br />
=== Build the Package ===<br />
<br />
# Build the package<br />
cd $PKG<br />
/sbin/makepkg -l y -c n $TMP/$APP-$PKG_VERSION-$ARCH-$BUILD.tgz<br />
<br />
= Other Concerns =<br />
<br />
=== DESTDIR Option Not Available ===<br />
<br />
As mentioned above, there are quite a few applications whose Makefiles do not support the DESTDIR option for make install. On some applications the DESTDIR Makefile variable has another name. For example, some Qt applications use the variable INSTALL_ROOT for the same purpose. If you can understand Makefiles, it is probably worth your time to take a look at its contents and try to find out which actions are performed in the install rule. Sometimes there will be no DESTDIR equivalent at all. The <strong>best</strong> thing you can do in this situation is write a patch for the Makefile.in or equivalent, and submit it to the developer(s) for inclusion in the source, but I realize that everyone doesn't have the ability to do that. The second best thing you can do it write to the developer(s) and ask them to include that functionality in future releases. In the meantime, here are some thoughts on the subject...<br />
<br />
==== Example 1: ====<br />
Configure the build with:<br />
./configure --prefix=$PKG/usr<br />
along with your other configure options. This will install *all* of the package contents in that directory. If the package creates $PKG/usr/etc and $PKG/usr/var directories (or any other directories that should be elsewhere), you can probably just move them to their correct location within the package directory tree and everything will be fine. You might also try this along with your other configure options.<br />
./configure --prefix=$PKG/usr \<br />
--sysconfdir=$PKG/etc \<br />
--localstatedir=$PKG/var <br />
There are some applications, however, which "hard-code" configuration files based on configure/Makefile parameters. In those cases, you'll have to figure out a way to patch the config file prior to packaging it, or in worst-case scenario, include instructions for the end user on how to make the necessary changes.<br />
<br />
==== Example 2: ====<br />
This example makes use of the ability to override any Makefile variable, which is called a '''macro''' in the Makefile terminology, on the command line and not have to worry about patching the Makefile to include a '''DESTDIR''' macro in the Makefile. This approach makes it a bit easier for those not familiar with Makefiles.<br />
<br />
If the Makefile does not honor '''DESTDIR''' for the 'make install' command, you can change the prefix macro, instead:<br />
make prefix=$PKG/usr install<br />
This will override the $(prefix) variable inside the Makefile and install to the location you supplied on the command line. Therefore, you can configure with the standard ''./configure --prefix=/usr'' (or ''./configure --prefix=/usr/local'') syntax, yet install to a different location as if you supplied a ''DESTDIR=$PKG/usr'' for the 'make install' command.<br />
<br />
IMPORTANT NOTE: Macro names are case-sensitive (at least for GNU make). Some Makefiles may use a "'''PREFIX ='''" macro instead of the usual "'''prefix ='''", so the 'make install' command would look like this:<br />
make PREFIX=$PKG/usr install<br />
Therefore, it's necessary to look inside the Makefile to be sure which form was used for the prefix. For large, complex makefiles, the easiest way is to 'grep' the Makefile, like so:<br />
grep -i '^prefix \?=' Makefile{,.in}<br />
The ''-i'' option makes the search case-insensitive and the ''{,.in}'' part at the end will search "Makefile" or "Makefile.in" files, the second one being a template for the "configure" script. Grep's search term is a basic regular expression, so the escaped question mark after the space (\?) means there may or may not be a space in between when searching.<br />
<br />
Once in a while, there may be a "'''PREFIX ='''" in a Makefile that is not defined which you are to edit and supply the location. Use the usual ''/usr'' (or ''/usr/local''), in this case, and then use 'make PREFIX=$PKG/usr install' to install to the package's build location.<br />
<br />
=== Patching the Sources ===<br />
<br />
Sooner or later, there will be some reason to patch the source code prior to building a package, and you'll want to be able to do this automatically. <br />
<br />
===== Obtaining the Patch =====<br />
<br />
In most cases, the patch will be provided by the author of the source code, so we're not going to discuss patch *creation* here. Download the patch and place it in the same directory as the SlackBuild script, slack-desc file, and other related files (in $CWD from above).<br />
$ wget http://someapplication.org/files/patches/bigsecuritypatch.diff<br />
It's not necessary to do the next step, but because developers generally want to conserve space if possible, it's conventional to do this:<br />
$ gzip -9 bigsecuritypatch.diff<br />
This will result in a new file called bigsecuritypatch.diff.gz -- we'll use that in the SlackBuild script in just a moment.<br />
<br />
===== Applying the Patch =====<br />
<br />
You will now need to edit your <application>.SlackBuild script so that it applies the patch before it runs configure, make, and make install. To do this, you'll want something like this to run before the configure script, but after extracting the sources:<br />
zcat $CWD/bigsecuritypatch.diff.gz | patch -p1 || exit<br />
Depending on how the patch was created, you might use a different patchlevel on that line, as in:<br />
zcat $CWD/bigsecuritypatch.diff.gz | patch -p0 || exit<br />
It's a bit beyond the scope of this HOWTO, but essentially, the -p# specifies the number of trailing directories to skip when looking for the file to patch. You'll often need to skip the top-level directory, but not always (hence the -p0).<br />
<br />
= See Also =<br />
<br />
* [[SlackBuild_Scripts]]<br />
* [[Different_Approach_To_Buildscripts]]<br />
* [[Building_A_Package]]<br />
* [[Slack-desc]]<br />
* [[Checkinstall]]<br />
* [[Compiling]]<br />
<br />
= SlackBuild Script Repositories =<br />
<br />
;* http://slackbuilds.org<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
;* http://slackbuilds.slackadelic.com/<br />
;* http://slackbuilds.rlworkman.net/<br />
;* http://www.slackbuilds.net/slackbuilds/<br />
;* http://slackbuild.strangeworlds.co.uk/<br />
;* http://www2.linuxpackages.net/packages/SlackBuilds/<br />
;* http://www.selkfoster.com.ar/downloads/slackbuilds/<br />
;* http://slack.sarava.org/slackbuilds/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=SlackBuild_Scripts&diff=572SlackBuild Scripts2011-12-09T14:12:51Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Dugan</p>
<hr />
<div>SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source. <br />
<br />
While not necessary to compile and create packages on Slackware, SlackBuilds serve as tools for scripting the compiling and packaging processes, which are often repetitive. Just as importantly, SlackBuilds also act as documentation of compile-time options and configurations for that particular package. For that reason, official Slackware packages come with SlackBuilds bundled with the source code, and the inclusion of a SlackBuild is desirable in third-party packages.<br />
<br />
== Using SlackBuild Scripts ==<br />
In this example I'm going to use the [http://www.pidgin.im Pidgin] slackbuild. First you find on the mirror in the source directory and download the whole directory of Pidgin:<br />
<br />
: <code>mkdir pidgin</code><br />
: <code>cd pidgin</code><br />
: <code>wget --passive-ftp <nowiki>ftp://slackware.at/slackware-12.1/source/xap/pidgin/*</nowiki></code><br />
<br />
This downloads the files needed for Slackware scripts. The same idea applies for SlackBuild scripts from other<br />
sources - you generally need to download all of the files in the directory that contains the build script. For example, in the pidgin source directory, you would need the following files:<br />
<br />
: <code>pidgin-2.4.1.tar.bz2 pidgin-encryption-3.0.tar.gz pidgin.SlackBuild* slack-desc </code><br />
<br />
There will sometimes be other files, such as doinst.sh, diff.gz patch files, and rc.* scripts in this directory.<br />
<br />
Now, say you want to get the newest version of pidgin? Well, you download the tar.bz2 file (in Pidgin, the script uses tar.bz2). Now you open up pidgin.Slackbuild:<br />
<br />
: <code>VERSION=2.4.1</code><br />
<br />
This is the line we are looking at. Now we can change this to<br />
<br />
: <code>VERSION=2.4.2</code><br />
<br />
Now you can edit the compile flags and other cool things not covered here. Now that we have downloaded and edited the SlackBuild script, let's make it executable:<br />
<br />
: <code>chmod +x pidgin.SlackBuild</code><br />
<br />
Now this is executable, and we want to run as root for permissions and other reasons so we want to become root:<br />
<br />
: <code>su -</code><br />
<br />
Now we start the script, and this will compile Pidgin and make a Slackware package. Depending on how the <br />
script is written, the resulting package will be in /tmp, some directory of /tmp, or perhaps some<br />
other location - have a look at the SlackBuild script for some hints if you can't find the package that<br />
was built. <br />
<br />
Once you find the package, you simply use 'installpkg' to install it normally (and you probably want to<br />
move it somewhere else on your system for safekeeping).<br />
<br />
: <code>./pidgin.SlackBuild</code><br />
<br />
=SlackBuild Archives=<br />
;* http://www.slackbuilds.org<br />
;* http://repository.slacky.eu<br />
;* http://www.slackware.com/~alien/slackbuilds/<br />
;* http://www.slackbuilds.net/slackbuilds/<br />
;* http://slackbuild.strangeworlds.co.uk/<br />
<br />
=Other Resources=<br />
For a bit more detailed tutorial, see this entry: [[Writing A SlackBuild Script]]<br />
<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Building_A_Package&diff=571Building A Package2011-12-09T14:12:49Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Vporpo</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
= Intro =<br />
<br />
This is a rough outline for building Slackware packages. Some steps may not be neccessary, some steps might be missing. Use the discussion page for side-notes such as using slacktrack (when DESTDIR fails) and other utilities like checkinstall.<br />
<br />
== The good and decent way ==<br />
<br />
Configure and compile the source as you usually do:<br />
./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc<br />
make<br />
<br />
Make a temporary destination directory available:<br />
mkdir /tmp/build<br />
<br />
Install into the temporary directory:<br />
make install DESTDIR=/tmp/build<br />
<br />
Now strip libs/bins within the temporary directory:<br />
strip -s /tmp/build/usr/lib/* /tmp/build/usr/bin/*<br />
<br />
You also want to make sure that anything in <tt>/usr/man</tt> is gzipped before you make the package:<br />
gzip -9 /tmp/build/usr/man/man?/*.?<br />
<br />
Create the <tt>install</tt> directory, this is where the description and install script will be stored:<br />
cd /tmp/build<br />
mkdir install<br />
cd install<br />
<br />
Using a text editor (or a [http://slack-desc.sourceforge.net/ tool]]), create a file called [[slack-desc]] and fill it with the following contents:<br />
<br />
|-----handy-ruler------------------------------------------------------|<br />
app: Application Name (Short/Brief description)<br />
app:<br />
app: Enter a description of the package you are building.<br />
app: All 11 "app:" lines must be present<br />
app: "app" needs to be your application name.<br />
app: The handy-ruler is there to help you, these lines should not exceed<br />
app: 79 characters.<br />
app:<br />
app:<br />
app:<br />
app:<br />
<br />
Create the actual package:<br />
cd /tmp/build<br />
makepkg ../app-version-arch-tag.tgz<br />
<br />
''(The dashes should appear as above, so if the version has a subversion like say "1.0 RC2" make sure you use 1.0_RC2 not 1.0-RC2. The arch should be something like "i486" for example. The tag should consist of the build number and your initals, e.g. 1zb for Zaphod Beeblebrox's first build, 2zb for his second build, etc. Official slackware packages have only numbers as tags.)''<br />
<br />
When prompted to recreate symbolic links, say <tt>yes</tt><br><br />
When prompted to reset permissions, say <tt>no</tt><br />
<br />
''Note: Using '''makepkg -l y -c n''' will give you the same behaviour as answering yes to the symlinks question, and no to the permissions question.''<br />
<br />
If all went well, you can now install the package.<br />
cd ..<br />
installpkg app-version-arch-tag.tgz<br />
<br />
<br />
== The "i don't have time" way ==<br />
<br />
Fortunately, Slackware are pretty flexible too. If you don't mind much about what is the source (beware!) that you're compiling you can burn some stages and do something like this: <br />
./configure --prefix=/usr<br />
make install DESTDIR=$(pwd)/PACKAGE<br />
cd $(pwd)/PACKAGE<br />
makepkg -l y -c n ../app-version-arch-tag.tgz<br />
installpkg ../app-version-arch-tag.tgz<br />
<br />
Of course, you will have a package without description, (probably) uncompressed man pages and unstripped binaries.<br />
<br />
----<br />
For more information, also see the pages on [[SlackBuild_Scripts]] and [[Different_Approach_To_Buildscripts]].<br />
----</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Slack-desc&diff=570Slack-desc2011-12-09T14:12:47Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Vporpo</p>
<hr />
<div>=Overview=<br />
A proper slack-desc file should be written as follows:<br />
<br />
# HOW TO EDIT THIS FILE:<br />
# The "handy ruler" below makes it easier to edit a package description. Line<br />
# up the first '|' above the ':' following the base package name, and the '|' on<br />
# the right side marks the last column you can put a character in. You must make<br />
# exactly 11 lines for the formatting to be correct. It's also customary to<br />
# leave one space after the ':'.<br />
<br />
|-----handy-ruler------------------------------------------------------|<br />
appname: appname (Short description of the application)<br />
appname: <this line is generally left blank><br />
appname: Description of application - this description should be fairly<br />
appname: in-depth; in other words, make it clear what the package does (and <br />
appname: maybe include relevant links and/or instructions if there's room),<br />
appname: but don't get too verbose. <br />
appname: This file can have a maximum of eleven (11) lines of text preceded by<br />
appname: the "appname: " designation. <br />
appname:<br />
appname: It's a good idea to include a link to the application's homepage too.<br />
appname:<br />
<br />
The "appname" string must *exactly* match the application name portion of the <br />
Slackware package (for example, a package titled "gaim-1.5-i486-1.tgz" must have <br />
a slack-desc file with the <appname> string of "gaim: " rather than "Gaim: " or <br />
"GAIM: " or something else.<br />
<br />
The first line ''must'' show the application name followed by a short<br />
description (enclosed in parentheses).<br />
<br />
The "handy ruler" is meant to stop you at 79 characters, because the standard<br />
console is 80x25 and if you go beyond this the words will wrap.<br />
<br />
The space after the : is needed only when there is text after the :<br />
In the above example lines 9 & 11 should not have a space after the :<br />
<br />
=Tools=<br />
1. There is a command-line tool that automates the creation of slack-desc files and helps you generate legal slack-desc files with minimal effort:<br />
http://slack-desc.sourceforge.net/<br />
<br />
2. A web-based tool is also available at: http://www.linuxpackages.net/slackcreator.php<br />
=See Also=<br />
man makepkg<br />
man pkgtool<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Kernel26Compilation&diff=569Kernel26Compilation2011-12-09T14:12:07Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>How to build a 2.6.x Kernel on Slackware<br />
<br />
Note: Maybe this replaces the 2.6 part of the kernel compile tutorial already here.<br />
<br />
==Warning!==<br />
If you work on your kernel and do something wrong you may destroy your system in a way you have to reinstall it. All actions on your own risk! Noone assures that all actions described here are 100% right and work in any case. We are not responsible for damages caused by following this tutorial!<br />
<br />
==Prerequisites==<br />
<br />
* Get the kernel sources you want from ftp://ftp.de.kernel.org or from a mirror (http://www.kernel.org/mirrors/).<br />
* Make sure you are able to boot your Slackware original kernel after kernel update (You have to install 2.6.13 from "testing" to do this-slack12 uses 2.6.21.5 by default, no need to install it)<br />
<br />
image = /boot/vmlinuz-generic-2.6.13<br><br />
root = /dev/ #Your root partition. Get this from another kernel entry or from original /etc/lilo.conf<br />
label = Backup<br />
read-only<br />
<br />
Now run "lilo" once as root<br />
* If you want to play safe you may now reboot and try if the kernel boots without errors.<br />
* Uncompress your kernel sources below /usr/src<br />
* The symlink /usr/src/linux has to point to the directory of the new kernel. For example: /usr/src/linux -> /usr/src/linux-2.6.14.4<br />
<br />
==Configure the kernel==<br />
<br />
* Change to the kernel directory.<br />
cd /usr/src/linux<br />
<br />
* Configure your kernel:<br />
** From scratch, then you may choose from<br />
<br />
make config (You get prompted for all possible options)<br />
make menuconfig (You get a nice menu where you may navigate with cursor keys. Needs curses-5.x)<br />
make xconfig (You may configure in X, of course needs working X installation)<br />
make gconfig<br />
make qtconfig<br />
<br />
:* From old configuration:<br />
Copy the config file of the old kernel to ./.config. If you want to come from orignal Slackware kernel, then:<br />
<br />
cp /boot/config .config<br />
<br />
After that "make oldconfig" to configure new features (you may acceppt all questions with "Enter" to use the default values) and use "make menuconfig" (or any other of the above list) to change things if you like.<br />
<br />
Important! Be sure to compile the alsa modules (or you won't have sound). You have also to do this if you used "make oldconfig" (for example using "make menuconfig") as the original kernel is compiled without alsa.<br />
<br />
==Compile and install kernel==<br />
<br />
* The real compiling can start:<br />
<br />
make (Now, depending on your computer, you may go drinking some coffee, watch a movie or go on your balcony to smoke one ;-) )<br />
<br />
If this finished without errors (we assume this) then your kernel and your kernel modules should be compiled.<br />
<br />
* Remove symlinks. If you still run your original slackware kernel, then "vmlinuz" and "System.map" are Symlinks to the kernel files. To get sure that we don't override this files, we delete the symlinks<br />
<br />
rm /boot/vmlinuz /boot/System.map<br />
<br />
* Install the kernel<br />
<br />
Install the kernel modules with:<br><br />
make modules_install<br />
<br />
and the kernel with:<br><br />
make install<br />
<br />
* If all steps have been done successful you may now use your new (self-made) kernel.<br />
<br />
==Troubleshooting==<br />
<br />
* Help, the kernel doesn't work!<br />
<br />
Choose your backup kernel on lilo, check your kernel configuration and recompile.<br />
<br />
* Choose your backup kernel sounds easy, but...<br />
<br />
Now you know why you should keep a running kernel before you install a new one. Either your system is as usable as you are able to check the kernel configuration or you may boot from your slackware setup CD, mount your root partition to /mnt, chroot /mnt and recompile your kernel from there or install slackware packages of a running kernel.<br />
<br />
[http://www.slackforum.de/wiki/Kernel26Kompilieren german version]<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Permissions_and_Umasks&diff=568Permissions and Umasks2011-12-09T14:11:36Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>==Normal Permissions==<br />
<br />
On *nix-like systems, traditionally every file has an owner, an assigned group, and a list of permissions (although POSIX Access Control Lists are getting more popular).<br />
<br />
You can change the owner of a file with the "chown" command:<br />
<br />
: <code>fred@linux:~> chown someUser foo</code><br />
<br />
You can change the group of a file with the "chgrp" command:<br />
<br />
: <code>fred@linux:~> chgrp someGroup foo</code><br />
<br />
Alternatively, you can do both at once:<br />
<br />
: fred@linux:~> <code>chown someUser.someGroup foo</code><br />
<br />
or:<br />
<br />
: fred@linux:~> <code>chown someUser:someGroup foo</code><br />
<br />
For every file, you can set the following for the User, Group, and Others: r - can read w - can write x - can execute<br />
<br />
These are set with the "chmod" command:<br />
<br />
: fred@linux:~> <code>chmod u=rwx,g=rx,o=r foo</code><br />
: fred@linux:~> <code>ls -l foo</code><br />
: -rwxr-xr-- 1 fred users 0 2004-10-26 11:38 foo<br />
<br />
You don't need to set all the permissions - you can just modify them, for example, to make a file executable:<br />
<br />
: fred@linux:~> <code>chmod +x foo</code><br />
<br />
You can also change the permissions just for either the User, Group, or Others:<br />
<br />
: fred@linux:~> <code>chmod o-x foo</code><br />
<br />
==Octal Permissions==<br />
<br />
You can also specify permissions with a number. To find out which numbers, add up the numbers from this table:<br />
<br />
r w x<br />
4 2 1<br />
<br />
For example, rwxr-xr-- would be:<br />
<br />
U G O<br />
4 4 4<br />
+2 +0 +0<br />
+1 +1 +0<br />
=7 =5 =4<br />
<br />
So to give a file rwxr-xr-- permissions:<br />
<br />
: fred@linux:~> <code>chmod 754 foo</code><br />
<br />
==Umasks==<br />
<br />
umasks define which permissions can not be set (in octal). For example, the default umask on slackware is 0022:<br />
<br />
: fred@laptop:~$ <code>umask</code><br />
: 0022<br />
<br />
Ignoring the first digit, this means that the owner can do anything, but group and others are unable to write (2 == w). A more secure umask (possibly more suitable for your ~/) is 0077, meaning that group and others have no access to your files.<br />
<br />
==More Umask==<br />
<br />
The following is based on [[User:Sandman1|Sandman1]]'s Umask tutorial.<br />
<br />
Well first this is a pretty boring topic to write about, So im going to get right to the point. When you set a umask you set what permission NOT to set. So when you create a file it uses the umask to set the file permissions. All of this might not make sense now but it will later. Now type:<br />
<br />
: <code>umask</code><br />
<br />
Now on slackware you will get "0022", First ignore the first 0. Now we have 022. The first 0 makes sure the owner has ALL the permissions of a file. You can tell that becuase you have no permissions you want to turn off. Now the next two numbers you have a 2 for. The 2 indicates that you NEVER want to set write permissions.<br />
<br />
Now that method above of trying to find a umask is a bit confusing. All you do is set the number what you DON'T want the user to have. Now there is an easier way of finding out a umask. You can subtract the permission from 777. Example:<br />
<br />
777 - 750 = 027<br />
<br />
That is the umask of the 750 permission. Now you may be asking yourself what is this usefull for. Well you can set the umask by typing "umask 027" in bash and when you create a file/directory it goes by umask 027 instead of the 0022.<br />
<br />
Now another reason for setting a umask is becuase you want to access a filesystem such as NTFS,VFAT,Samba,etc as a regular user. You can set the umask and allow regular users to write to the filesytem. It is really easy, in the fstab all you add is "umask=027" and remount the filesystem.<br />
See [[Windows_Partitions]] for more information (and a potentially better option than setting umask options).<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Different_Approach_To_Buildscripts&diff=567Different Approach To Buildscripts2011-12-09T14:11:17Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Dugan</p>
<hr />
<div>[[Category:Tutorials]]<br />
Pretty much everyone can have their own way of writing Slackware buildscripts. I also have mine, which just makes it easier for me to package software.<br />
<br />
In here, I'm going to explain mine. To start, let's look at one I wrote this morning while drinking coffee cup #1:<br />
<br />
#!/bin/bash<br />
<br />
#############################################################################<br />
## Name: jpilot ##<br />
## Version: 0.99.8 ##<br />
## Packager: Martin Lefebvre (dadexter@gmail.com) ##<br />
## Homepage: http://www.jpilot.org ##<br />
#############################################################################<br />
<br />
PKGNAME=jpilot<br />
VERSION=0.99.8<br />
LOC="http://jpilot.org/$PKGNAME-$VERSION.tar.gz"<br />
ARCH=`uname -m`<br />
<br />
START=`pwd`<br />
PKG=$START/pkg<br />
SRC=$START/work<br />
<br />
build() {<br />
mkdir -p $PKG $SRC<br />
cd $SRC<br />
wget $LOC<br />
tar -zxvf $PKGNAME-$VERSION.tar.gz<br />
cd $PKGNAME-$VERSION<br />
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \<br />
--enable-gtk2 --enable-prometheon<br />
<br />
patch -p0 < patch.0.99.8-memory<br />
patch -p0 < patch.jpilot-sync<br />
make<br />
make DESTDIR=$PKG install<br />
mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION<br />
cp -r ABOUT-NLS AUTHORS BUGS COPYING ChangeLog ChangeLog.cvs INSTALL \<br />
NEWS README TODO UPGRADING docs $PKG/usr/doc/$PKGNAME-$VERSION<br />
<br />
cp KeyRing/README.txt $PKG/usr/doc/$PKGNAME-$VERSION/README.keyring<br />
cp dialer/README $PKG/usr/doc/$PKGNAME-$VERSION/README.dialer<br />
cp icons/README $PKG/usr/doc/$PKGNAME-$VERSION/README.icons<br />
}<br />
<br />
package() {<br />
cd $PKG<br />
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : \<br />
| xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : \<br />
| xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | \<br />
xargs strip --strip-debug 2> /dev/null<br />
chown -R root:root usr/bin<br />
gzip -p $PKG/usr/man/man*/*<br />
mkdir $PKG/install<br />
cp $START/slack-desc $PKG/install/slack-desc<br />
cd $PKG<br />
makepkg -l y -c n $START/$PKGNAME-$VERSION-$ARCH-1.tgz<br />
}<br />
<br />
build<br />
package<br />
<br />
<br />
The top section is just comments identifying the piece of software we're going to build, and the name of the script's author. Then we have the following lines:<br />
<br />
PKGNAME=jpilot<br />
VERSION=0.99.8<br />
LOC="http://jpilot.org/$PKGNAME-$VERSION.tar.gz"<br />
ARCH=`uname -m`<br />
<br />
START=`pwd`<br />
PKG=$START/pkg<br />
SRC=$START/work<br />
<br />
They set the program's name, version, download URL, build and package directories. Since I usually don't specify anything related to the cpu or architecture, it auto detects the architecture. So, the $ARCH variable *should be* accurate.<br />
<br />
build() {<br />
mkdir -p $PKG $SRC<br />
cd $SRC<br />
wget $LOC<br />
tar -zxvf $PKGNAME-$VERSION.tar.gz<br />
cd $PKGNAME-$VERSION<br />
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \<br />
--enable-gtk2 --enable-prometheon<br />
<br />
patch -p0 < patch.0.99.8-memory<br />
patch -p0 < patch.jpilot-sync<br />
make<br />
make DESTDIR=$PKG install<br />
mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION<br />
cp -r ABOUT-NLS AUTHORS BUGS COPYING ChangeLog ChangeLog.cvs INSTALL \<br />
NEWS README TODO UPGRADING docs $PKG/usr/doc/$PKGNAME-$VERSION<br />
<br />
cp KeyRing/README.txt $PKG/usr/doc/$PKGNAME-$VERSION/README.keyring<br />
cp dialer/README $PKG/usr/doc/$PKGNAME-$VERSION/README.dialer<br />
cp icons/README $PKG/usr/doc/$PKGNAME-$VERSION/README.icons<br />
}<br />
<br />
The is the main build function. This contains the code required to build the software. First, we create the build and package directories. The next 3 lines change to the building diirectory, uses wget to fetch the source file and extracts it.<br />
<br />
The lines after that are what you would normally type at your command line to build the software:<br />
<br />
* Change to the source directory.<br />
* Run ./configure with all the options you want.<br />
* Apply two patches required (in this case) to fix bugs with the software.<br />
* Run make<br />
* Install the software in the package directory defined by $PKG<br />
* Create the standard Slackware Software Documentation directory in the package<br />
* Copy the standard documentation.<br />
<br />
<br />
The next section is the packaging part:<br />
<br />
package() {<br />
cd $PKG<br />
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : \<br />
| xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : \<br />
| xargs strip --strip-unneeded 2> /dev/null<br />
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | \<br />
xargs strip --strip-debug 2> /dev/null<br />
chown -R root:root usr/bin<br />
gzip -p $PKG/usr/man/man*/*<br />
mkdir $PKG/install<br />
cp $START/slack-desc $PKG/install/slack-desc<br />
cd $PKG<br />
makepkg -l y -c n $START/$PKGNAME-$VERSION-$ARCH-1.tgz<br />
}<br />
<br />
* We change to the package directory<br />
* Strip executables and libraries in order to decrease size.<br />
* As a Slackware standard, we change the ownership of the executables to root:root (to be done for every bin/ and sbin/ directory)<br />
* We compress the manpages<br />
* Create install/ and copy the slack-desc file from the start directory<br />
* Finally, change back to the package folder and create the package tarball.<br />
<br />
<br />
In this example, the slack-desc and some patch files are distributed with the SlackBuild. This also makes it easier to ship the build script with patches that might be required for the software to work on Slackware (patch to remove PAM stuff).<br />
<br />
The slack-desc file format is described here: [http://www.linuxpackages.net/howto.php?page=slack-desc&title=Slackware+Desc+Files LinuxPackages.net]<br />
<br />
<br />
Additional files:<br />
<br />
Some people use slapt-get (like me). slapt-get supports additional features such as<br />
* Dependencies<br />
* Conflicts<br />
* Suggestions<br />
<br />
Not everyone wants those features, so building a package with those files will not interfere with the normal pkgtools process. For more info on these optional files, go here: [http://www.linuxpackages.net/howto.php?page=perfect-package&title=Perfect+Package#Optional LinuxPackages.net]<br />
<br />
If you decide to use those files, you will then have to repeat these lines:<br />
<br />
cp $START/slack-desc $PKG/install/slack-desc<br />
<br />
for slack-required, slack-conflicts, and slack-suggests.<br />
<br />
<br />
----<br />
See also [[SlackBuild_Scripts]] and [[Writing A SlackBuild Script]]<br />
----</div>Rworkmanhttps://www.slackwiki.com/index.php?title=NVIDIA-Prompted-Kernel-Compile&diff=566NVIDIA-Prompted-Kernel-Compile2011-12-09T14:07:35Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Erik</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
=== nVidia Graphics Driver Installation & Kernel Recompile in Slackware 12.0 ===<br />
<br />
====Warning!====<br />
----<br />
<br />
:Please do all this at your own risk. If you change your kernel and cause any damage to your system, you and only you are responsible for it. By providing this tutorial I do not take any responsibility for any damages or losses to your system. This is a disclaimer!<br />
<br />
==== Background Info & Rationale for Kernel Recompile ====<br />
----<br />
:I recently bought a used ''Geforce N6200'' video card (nvidia chipset) to replace the ''ATI Radeon 9200SE'' that suddenly died on me. I ran Xorg configuration utility ''xorgconfig'' to set the new card up. Slackware 12.0 ships with a generic ''nv'' driver for nvidia cards, but it does not support graphics acceleration and/or direct rendering. That means no games and no graphic heavy websites. Fortunately, nvidia provides a Linux binary driver for your video card that will do direct rendering and 3D acceleration just fine, although the driver is closed-source. But hey, at least it works.<br />
<br />
:Assuming that you're running Slackware 12.0 and using huge generic kernel 2.6.21.5 or newer or the smp version of it, you are going to face some problems compiling the nvidia driver against that kernel. The nvidia installer utility compiles the binary driver to suit your kernel. In Slackware 12.0 the support for Riva framebuffer is enabled by default in the huge-2.6.21.5 and huge-2.6.21.5-smp kernels and it is a problem for the nvidia installer utility. As soon as it notes the riva support enabled in the kernel header files, it quits and the driver module compilation fails. Most people will experience this problem in Slackware 12.0. The solution is to disable riva framebuffer support from the kernel and recompile it.<br />
<br />
:At the end of this tutorial you will have a fresh kernel compiled for your system, the nvidia driver compiled against this kernel and installed as kernel module and 3D graphics acceleration as well as direct rendering enabled. So let's begin taking one thing at a time.<br />
<br />
<br />
==== Back Up Current Kernel & Kernel Modules ====<br />
----<br />
<br />
:It is important that you have a backup of your currently working kernel modules so if the new kernel fails, you would still be able to use the old kernel to boot the system. Let's play safe. Important: All steps in this tutorials are done as superuser.<br />
<br />
cd /lib/modules<br />
ls<br />
2.6.21.5 2.6.21.5-smp<br />
<br />
:Above currently installed kernels on your system are listed. Rename the kernel you're using to something like ''kernel-name''.backup. If you do not know which kernel you're using, do the following. The output of it should list the kernel you're using. Once you find it out, rename it as follows.<br />
<br />
uname -a<br />
Linux 2.6.21.5 #1 Sun Mar 16 14:46:57 CDT 2008 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux<br />
<br />
mv 2.6.21.5 2.6.21.5-backup<br />
ls<br />
2.6.21.5-smp 2.6.21.5-backup<br />
<br />
==== Kernel Configuration and Recompile ====<br />
----<br />
<br />
:Now that we have a backup of our current kernel and its modules, its time to proceed with configuration and recompiling the kernel. Change to the kernel source directory and copy the current kernel config file to the kernel source directory<br />
<br />
cd /usr/src/linux<br />
cp /boot/config .config #Note that config in /boot has no dot before it, but when we copy it, we include a dot prefix.<br />
<br />
This step will copy your current configuration so we can use it as a reference for further steps. Now let's begin kernel configuration<br />
<br />
make menuconfig<br />
<br />
This should give you a nice ''ncurses'' style detailed graphical menu of kernel configuration. <br />
<br />
Select Device Drivers > Graphics Support > <br />
<br />
:Scroll down to ''Riva Framebuffer Support'' (not ''nvidia Riva Support'') and press space bar twice. First space bar press will change the <M> to <*> and second will change <*> to < > (blank). Now press ''exit'' three times. The menuconfig will ask you if you want to save the changes. Select ''Yes'' and quit. We have now removed Riva Framebuffer Support from kernel configuration, the culprit for failing nvidia driver module compilation.<br />
<br />
:It's time to compile the kernel. Do the following:<br />
<br />
make bzImage<br />
<br />
:This is a good time to take a break for any of these: Coffee / Tea / Cigarette / Quick run to the grocery store. In short, depending upon how fast your procesor is, this step will take anywhere between 15 minutes to an hour. If everything goes fine, it will compile a new kernel and install newly compiled modules in /lib/modules/. If you get errors, something went wrong and you'll need to get some help from kernel documentation or ask in ##slackware on IRC host ''freenode.net''<br />
<br />
:Now that we have a kernel compiled, its time to compile and install kernel modules<br />
<br />
make modules && make modules_install<br />
<br />
:Again, this step will take some time. But it will be worth the wait. In the basic kernel, there is close to 1000 modules that need to be compiled. Once this step is finished and you did not get any errors, its time to make sure the kernel bzImage was created and the modules were installed to the appropriate location.<br />
<br />
pwd<br />
/usr/src/linux<br />
cd arch/i386/boot<br />
pwd<br />
/usr/src/linux/arch/i386/boot<br />
ls<br />
Makefile bootsect.S '''bzImage''' edd.S mtools.conf.in setup.S tools vmlinux.bin<br />
bootsect bootsect.o compressed install.sh setup setup.o video.S<br />
<br />
:bzImage is your newly compiled kernel without Riva framebuffer support.<br />
<br />
cd /lib/modules<br />
ls<br />
2.6.21.5 2.6.21.5-smp 2.6.21.5-backup<br />
<br />
The first entry above is the location of your newly installed kernel modules.<br />
<br />
==== Install New Kernel And Update lilo.conf ====<br />
----<br />
<br />
:Time to install the new kernel and notify your boot loader of its existence.<br />
<br />
cd /usr/src/linux/arch/i386/boot<br />
cp bzImage /boot<br />
<br />
:Open your favorite text editor and add following lines to your boot loader (typically /etc/lilo.conf)<br />
<br />
cd /etc<br />
emacs -nw lilo.conf<br />
<br />
#Linux bootable partition config begins<br />
image = /boot/bzImage<br />
root = /dev/hda2 #or whatever partition your / is located on <br />
label = New-Kernel #You can name it whatever you want. Just don't name it the same as the old kernel<br />
#Linux bootable partition config ends<br />
<br />
:Save file, close it and run lilo so the new changes take effect.<br />
<br />
lilo<br />
Added *Linux<br />
Added *New-Kernel<br />
<br />
:Excellent! It's time to test the new kernel. When you reboot, lilo will now present you with two choices for kernel, use the New-Kernel and boot. If somehow it fails, you can always go back to the old kernel. Just rename the /lib/modules/2.6.21.5-backup as 2.6.21.5 and rename the new kernel modules as something else. You see how important it was for us to backup the kernel as well as kernel modules in the beginning?<br />
<br />
:Assuming that your new kernel booted just fine and you had a fully functional system back up, its time to get the nVidia graphics driver from nvidia.com and install it. The current incarnation of nVidia driver is version # 169.12. Either use your favorite browser to download the driver from http://www.nvidia.com/Download/index.aspx?lang=en-us or do the following:<br />
<br />
cd /tmp<br />
wget http://us.download.nvidia.com/XFree86/Linux-x86/169.12/NVIDIA-Linux-x86-169.12-pkg1.run<br />
<br />
Make the installer utility executable and execute it<br />
<br />
chmod 755 NVIDIA-Linux-x86-169.12-pkg1.run<br />
ls -la<br />
-rwxr-xr-x 1 user groupname 17636559 2008-03-17 13:06 NVIDIA-Linux-x86-169.12-pkg1.run<br />
<br />
Before we execute it, we need to exit the X server. <br />
<br />
telinit 3 #This changes runlevel to 3, shuts down the X server and drops you off at the terminal <br />
sh ./NVIDIA-Linux-x86-169.12-pkg1.run<br />
<br />
:This installer utility first tries to find a pre-compiled driver for your kernel which it would not find, then it tries to download it via ftp from nvidia servers which fails too, and finally it proceeds to compile the driver kernel module against your newly installed bzImage kernel. This time, there is no riva framebuffer in the kernel header files and so this step should not fail. Should it fail, ask for help in your local LUG or the highly knowledgeable folks at ##slackware in irc channel freenode.net<br />
<br />
==== Updating X.Org Configuration File ====<br />
----<br />
<br />
:After the installer utility finishes compiling and installing kernel module for the nvidia driver, it will ask you if you want it to make appropriate changes to your /etc/X11/xorg.conf. I personally chose not to, because I did not want my already customized xorg.conf to be messed with by a third party software. I simply changed the driver name from '''nv''' to '''nvidia''' in the <device> section of /etc/X11/xorg.conf<br />
<br />
:That's it folks. You now have a new kernel, new kernel modules and nvidia driver with 3D acceleration and direct rendering. Check direct rendering as follows:<br />
<br />
glxinfo | grep dri<br />
<br />
:Third line of the output should tell you that Direct Rendering has been enabled. Now its time to fire up X server and check your new driver.<br />
<br />
telinit 4<br />
<br />
:This should launch X server, you should be seeing a flash of nvidia screen and then back to your favorite window manager. If everything went fine, you should go ahead and check video performance with some game, or a graphics intensive website or such.<br />
<br />
==== Acknowledgements ====<br />
----<br />
<br />
:This article benefited substantially by input from ##slackware (irc.freenode.net) user '''InspectorCluseau'''<br />
<br />
:If you have any questions or if you find a mistake in this tutorial, please contact me at [mailto:crypticlineage@gmail.com]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Windows_Partitions&diff=565Windows Partitions2011-12-09T14:06:35Z<p>Rworkman: Reverted edits by Esmapebb (talk) to last revision by Rworkman</p>
<hr />
<div>One of the frequent questions on ##slackware is something along the lines of "How can I allow normal users to access my Windows partition?" There are *at least* two different ways of doing this.<br />
<br />
For a FAT partition, you *could* add umask=0000 to /etc/fstab's options, but I personally don't recommend doing that. It's *your* computer, so you make the call, but I would do something along these lines:<br />
1. If you want *every* user to be able to read and write to the partition, then you can add dmask=0000 and fmask=0111 to /etc/fstab's options and be done with it - problem solved.<br />
<br />
/dev/hda1 /mnt/win98 vfat rw,dmask=0000,fmask=0111 0 0<br />
<br />
The reason for dmask/fmask as opposed to umask is quite obvious (though I hadn't thought about it until elohim on ##slackware pointed it out): The FAT and NTFS file systems don't "understand" the executable (-x) bit, so it's automatically present on every file in such a filesystem. There's no need for normal files to be executable (and it can indeed be a security risk), so we use fmask to turn off those permissions.<br />
<br />
2. If you only want some users to be able to read and write to the partition, but you want *every* user to have read access, then you'll want something along these lines. First, create a special group called "windows" (change the name if you wish) by adding it to /etc/group using your favorite editor and add to this group the users you want to have write access. <br />
<br />
nogroup:x:99:<br />
users:x:100:<br />
console:x:101:<br />
windows:x:102:user1,user2,user3<br />
<br />
Next, edit your /etc/fstab line for that partition and specify that it be mounted with group ownership of the "windows" group, and that write access be removed from others.<br />
<br />
/dev/hda1 /mnt/win98 vfat rw,gid=102,dmask=0002,fmask=0113 0 0<br />
<br />
An NTFS partition will be mounted read-only, so you won't have write access for anyone, but the central idea is the same.<br />
<br />
If you don't want everyone else to even have read access to the partition, you can easily do that with the above fstab line modified a bit:<br />
<br />
/dev/hda1 /mnt/winXP ntfs ro,gid=102,dmask=0227,fmask=0337 0 0<br />
<br />
If you prefer write access to the partition, then you can use ntfs-3g instead and something like this:<br />
All users can read the partition; only members of gid 102 can write:<br />
/dev/hda1 /mnt/win98 ntfs-3g rw,gid=102,dmask=0002,fmask=0113 0 0<br />
Users of gid can read and write; nobody else can do anything:<br />
/dev/hda1 /mnt/winXP ntfs-3g rw,gid=102,dmask=0007,fmask=0117 0 0<br />
<br />
For more information, see the [[Permissions and Umasks]] and [[Fstab]] pages.<br />
<br />
--rworkman (thanks to Erik for the pointers about dmask and fmask)<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=ALSA&diff=420ALSA2010-10-06T14:18:08Z<p>Rworkman: Modernization</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
Sound problems *should* be rare these days, and of the ones that still exist, they are likely related to suspend/resume. Those are driver issues which are largely out of your control, but see the documentation with the pm-utils package for details on handling those issues.<br />
<br />
: <code>alsaconf</code> used to be needed to set up sound cards in linux, but even that shouldn't be needed in recent linux distributions - everything should be handled automatically.<br />
<br />
: <code>alsamixer</code> can be used to change the volume.<br />
<br />
: <code>alsactl store</code> is used to save the volume settings.<br />
<br />
: <code>alsactl restore</code> is used to restore the volume settings. This is automatically run on boot, so you usually won't need to run this command.<br />
<br />
There is one tip for the Sound Baster 5.1 cards: sometimes you want to MUTE digital out so you can hear on all the speakers; in alsamixer, you just press M on the <tt>Analog/Digital Output Jack</tt> item.</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Basic_Security_Fixes&diff=419Basic Security Fixes2010-10-05T17:43:04Z<p>Rworkman: s/too/to/</p>
<hr />
<div>Small tips to increase the security of your Slackware box:<br />
<br />
* Use strong passwords! The most common way Linux systems get hacked is through weak user passwords and SSH.<br />
* Use a firewall! [http://www.freshmeat.net Freshmeat.net] has lots of automatic tools to help with configuration, and we have some example scripts posted [[Iptables_Scripts|here]].<br />
* Tell X not to listen for TCP connections:<br />
** KDM: Add "ServerArgsLocal=-nolisten tcp" under section [X-:*-Core] to /opt/kde/share/config/kdm/kdmrc<br />
** XDM: Add "-nolisten tcp" to the line calling X in /etc/X11/xdm/Xservers.<br />
** Console: Use 'startx -- -nolisten tcp' rather than 'startx', possibly with the aid of an alias.<br />
***: You can also edit startx and, at line 168 (where it calls xinit), append '-nolisten tcp' at the end, but this is a dirty hack.<br />
* Close any services you do not require, especially since most run as root. Think about what you will use them for. For instance, would you really want to run an sshd 24/7 when you will only perhaps access it remotely once in a blue moon, of which you will most likely know about in advance at which point you can run the required deamon prior to accessing remotely.<br />
** To disable startup services in /etc/rc.d, unset the executable bit of the rc script. You can still start and stop services by executing the rc script later using 'sh'.<br />
** You can also edit /etc/rc.d/rc.M directly and comment out lines that calls the other rc scripts.<br />
* Disable the "time" service, by commenting out lines 22 and 23 in /etc/inetd.conf - you will need to restart inetd after making the changes. (If you need to run inetd at all!)<br />
* Look for any services/daemons that you don't know about by running "netstat -luntp".<br />
* Run 'ps -e u' several times and become familiar with your usual processes to establish a "baseline". Then keep monitoring regularly to spot when something doesn't seem right.<br />
* If you suspect intrusion or have suspicious files, scan your system for rootkits with 'chkrootkit'. You can also scan for win32 "malware" with 'clamav' for instance if you're using your system as a mail/ftp server.<br />
* Add the following line to hosts.deny to disallow access by any host to your system... 'ALL: ALL' - note that this only affects services built with libwrap (tcpwrappers), but it's one layer of security. A further layer would be to add the following to /etc/hosts.allow... 'ALL: ALL: DENY'<br />
* Fine tune logrotate by editing /etc/logrotate.conf and add more log rotations in /etc/logrotate.d/<br />
<br />
* If you want to restrict who is able to use the su command to switch to certain users, you can use /etc/suauth. The basic format for /etc/suauth is "to-id:from-id:ACTION"<br />
<br />
:Example:<br />
<br />
root:foobar:DENY <br />
<br />
:would stop the user foobar from using su to become root.<br />
<br />
:Another example:<br />
<br />
root:ALL EXCEPT GROUP wheel:DENY<br />
<br />
:would only allow users in the wheel group to su to root. <br />
<br />
:You can also allow users to su with no password required (why you would do this is beyond me), and can require that a user enter their OWN password before switching users. For more information, please consult the man page for /etc/suauth. <br />
<br />
:(Thanks to cubicool for informing me of the existence of /etc/suauth)<br />
<br />
:A similar, though perhaps not as fine-grained, way to control who can use su is to change ownership and permissions of /bin/su. First, add the user(s) that you want to be able to use su to the wheel group in /etc/passwd. Next, change the ownership of /bin/su to group wheel, and change its permissions to 4750.<br />
chown root:wheel /bin/su<br />
chmod 4750 /bin/su<br />
:This makes /bin/su executable *only* by members of the wheel group.<br />
<br />
* Another way to restrict the users who can become root is to edit the file /etc/login.defs and change the value of SU_WHEEL_ONLY to yes.<br />
<br />
[[Category:Tips]]<br />
[[Category:Security]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Links&diff=418Links2010-10-05T17:40:36Z<p>Rworkman: Removed backtrack from the list</p>
<hr />
<div>[[Category:Information]]<br />
<br />
==Slackware Links==<br />
* http://www.slackware.com - the home of Slackware<br />
* http://www.chaosbits.net/Articles/Historical/SlackwareFAQ/ - Slackware FAQ by [[User:juhl|juhl]] (Jesper Juhl)<br />
* http://www.slackbook.org - updated version of the slackware book<br />
* http://www.slackware.com/getslack - Extensive listing of Slackware mirrors<br />
* http://www.linuxquestions.org/questions/slackware-14/ - Slackware forum<br />
* http://slackbuilds.org/ - Build scripts for additional software<br />
* http://sbopkg.org - Sbopkg is a command-line and dialog-based tool to synchronize with the SlackBuilds.org repository<br />
* http://www.kde-look.org/content/show.php?content=23384 - Slack-Track - a superkaramba theme to track the slackware-current changelog on your desktop, created by [[User:omal|omal]]<br />
* http://jtgzmanager.sf.net/ - A new frontend to pkgtools built with Qt4 C++ libs - by Alexandre Arnt<br />
* http://slackbot.sourceforge.net - Buildsystem and buildtools for Slackware<br />
* http://slackware.linux.or.id - Indonesian Slackware Community - by [[User:Willysr|Willysr]]<br />
* http://open-eslack.org/ - Spanish Slackware community<br />
* http://www.slack-world.com - Iranian Slackware Community<br />
<br />
==General Links==<br />
* http://freshmeat.net - large index of Unix and cross-platform software and themes<br />
* http://sourceforge.net - large repository of Open Source code and applications<br />
* http://developer.berlios.de - another Open Source repository - ideal if you want subversion hosting for your project<br />
* http://art.gnome.org - gnome-desktop themes and backgrounds<br />
* http://www.gnome-look.org - eyecandy for your gnome-desktop<br />
* http://www.kde-look.org - eyecandy for your KDE desktop<br />
* http://www.kde-apps.org - Applications and addons for KDE<br />
* http://kerneltrap.org - Kernel talk<br />
* http://urbanmyth.org/microcode/ - The latest microcode for your Intel CPUs<br />
<br />
==Slack==<br />
* http://www.subgenius.com - The [[Church of the SubGenius]]: the source of the term "Slack"<br />
* http://www.modemac.com/x-day - X-Day<br />
* http://en.wikipedia.org/wiki/Church_of_the_SubGenius - Wikipedia entry<br />
<br />
==Free packages==<br />
<br />
<br />
* [http://slackware.com/~alien/ http://slackware.com/~alien/] Eric Hameleers' packages<br />
* [http://rlworkman.net/pkgs/ http://rlworkman.net/pkgs/] rworkman's packages<br />
* http://www.linuxpackages.net/<br />
* [http://www.slacky.eu/repository/slackware-11.0/ Slacky.eu] Italian Slackware site<br />
* [http://slacke17.sourceforge.net/ SlackE17] A distribution of Enlightenment DR17 for Slackware<br />
* [http://scxd.info/en/ Slackware Current eXtended Desktop] Packages for Slackware Current<br />
<br />
==.SlackBuild Repositories==<br />
* http://slackbuilds.org - The SlackBuilds.org Project<br />
* http://slackbuilds.net - The French SlackBuilds Repository<br />
* http://www.slackware.com/~alien/slackbuilds/ - Eric "Alien" Hameleer's SlackBuilds<br />
* http://slackbuild.strangeworlds.co.uk - cathectic's SlackBuilds<br />
* http://buildpkg.berlios.de/ - buildpkg: a Slackware package building utility.<br />
* http://scxd.info/pub/slackbuilds/ - Slackware Current eXtended Desktop's SlackBuilds<br />
<br />
==Live CD's based on Slackware==<br />
* [http://mutagenix.org Mutagenix] A basic rescue CD and a Freerock GNOME based desktop CD<br />
* [http://www.slax.org Slax Homepage]<br />
* [http://slampp.abangadek.com SLAMPP Homepage]<br />
<br />
==Other Wikis==<br />
* [http://www.slackforum.de/wiki/ A German Slackware Wiki]<br />
* [http://alien.slackbook.org/ Alien Bob's Wiki]<br />
* http://open-eslack.org/wiki/ - Wiki of the Slackware spanish community<br />
* http://slackware.linux.or.id/wiki/ - Indonesian Slackware Wiki<br />
<br />
==RSS Feeds==<br />
* http://dev.slackware.it/rss/ - RSS feeds for stable Slackware release and -current ChangeLog<br />
* http://slackbuilds.org/mirror/rss/ - ChangeLog RSS feeds for 8.1 through -current</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Links&diff=417Links2010-10-05T17:39:11Z<p>Rworkman: Removed some dead and unmaintained links and a bit of reorg</p>
<hr />
<div>[[Category:Information]]<br />
<br />
==Slackware Links==<br />
* http://www.slackware.com - the home of Slackware<br />
* http://www.chaosbits.net/Articles/Historical/SlackwareFAQ/ - Slackware FAQ by [[User:juhl|juhl]] (Jesper Juhl)<br />
* http://www.slackbook.org - updated version of the slackware book<br />
* http://www.slackware.com/getslack - Extensive listing of Slackware mirrors<br />
* http://www.linuxquestions.org/questions/slackware-14/ - Slackware forum<br />
* http://slackbuilds.org/ - Build scripts for additional software<br />
* http://sbopkg.org - Sbopkg is a command-line and dialog-based tool to synchronize with the SlackBuilds.org repository<br />
* http://www.kde-look.org/content/show.php?content=23384 - Slack-Track - a superkaramba theme to track the slackware-current changelog on your desktop, created by [[User:omal|omal]]<br />
* http://jtgzmanager.sf.net/ - A new frontend to pkgtools built with Qt4 C++ libs - by Alexandre Arnt<br />
* http://slackbot.sourceforge.net - Buildsystem and buildtools for Slackware<br />
* http://slackware.linux.or.id - Indonesian Slackware Community - by [[User:Willysr|Willysr]]<br />
* http://open-eslack.org/ - Spanish Slackware community<br />
* http://www.slack-world.com - Iranian Slackware Community<br />
<br />
==General Links==<br />
* http://freshmeat.net - large index of Unix and cross-platform software and themes<br />
* http://sourceforge.net - large repository of Open Source code and applications<br />
* http://developer.berlios.de - another Open Source repository - ideal if you want subversion hosting for your project<br />
* http://art.gnome.org - gnome-desktop themes and backgrounds<br />
* http://www.gnome-look.org - eyecandy for your gnome-desktop<br />
* http://www.kde-look.org - eyecandy for your KDE desktop<br />
* http://www.kde-apps.org - Applications and addons for KDE<br />
* http://kerneltrap.org - Kernel talk<br />
* http://urbanmyth.org/microcode/ - The latest microcode for your Intel CPUs<br />
<br />
==Slack==<br />
* http://www.subgenius.com - The [[Church of the SubGenius]]: the source of the term "Slack"<br />
* http://www.modemac.com/x-day - X-Day<br />
* http://en.wikipedia.org/wiki/Church_of_the_SubGenius - Wikipedia entry<br />
<br />
==Free packages==<br />
<br />
<br />
* [http://slackware.com/~alien/ http://slackware.com/~alien/] Eric Hameleers' packages<br />
* [http://rlworkman.net/pkgs/ http://rlworkman.net/pkgs/] rworkman's packages<br />
* http://www.linuxpackages.net/<br />
* [http://www.slacky.eu/repository/slackware-11.0/ Slacky.eu] Italian Slackware site<br />
* [http://slacke17.sourceforge.net/ SlackE17] A distribution of Enlightenment DR17 for Slackware<br />
* [http://scxd.info/en/ Slackware Current eXtended Desktop] Packages for Slackware Current<br />
<br />
==.SlackBuild Repositories==<br />
* http://slackbuilds.org - The SlackBuilds.org Project<br />
* http://slackbuilds.net - The French SlackBuilds Repository<br />
* http://www.slackware.com/~alien/slackbuilds/ - Eric "Alien" Hameleer's SlackBuilds<br />
* http://slackbuild.strangeworlds.co.uk - cathectic's SlackBuilds<br />
* http://buildpkg.berlios.de/ - buildpkg: a Slackware package building utility.<br />
* http://scxd.info/pub/slackbuilds/ - Slackware Current eXtended Desktop's SlackBuilds<br />
<br />
==Live CD's based on Slackware==<br />
* [http://www.remote-exploit.org/ BackTrack] The result of the merging of two Innovative Penetration Testing live Linux distributions: Whax and Auditor<br />
* [http://mutagenix.org Mutagenix] A basic rescue CD and a Freerock GNOME based desktop CD<br />
* [http://www.slax.org Slax Homepage]<br />
* [http://slampp.abangadek.com SLAMPP Homepage]<br />
<br />
==Other Wikis==<br />
* [http://www.slackforum.de/wiki/ A German Slackware Wiki]<br />
* [http://alien.slackbook.org/ Alien Bob's Wiki]<br />
* http://open-eslack.org/wiki/ - Wiki of the Slackware spanish community<br />
* http://slackware.linux.or.id/wiki/ - Indonesian Slackware Wiki<br />
<br />
==RSS Feeds==<br />
* http://dev.slackware.it/rss/ - RSS feeds for stable Slackware release and -current ChangeLog<br />
* http://slackbuilds.org/mirror/rss/ - ChangeLog RSS feeds for 8.1 through -current</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Main_Page&diff=263Main Page2009-11-03T06:06:25Z<p>Rworkman: Noted registration lapse</p>
<hr />
<div>Welcome to slackwiki! Feel free to [[Special:Userlogin|Create an account or log in]] and edit any of the pages, or add your own (see [http://meta.wikimedia.org/wiki/Help:Starting_a_new_page Starting A New Page]). Come talk to some of us in ##slackware on irc.freenode.net. When saving changes, please provide a brief summary of your changes in the box provided - it's nice for those sad people who follow [[Special:Recentchanges|RecentChanges]] via RSS. Any questions about the wiki? See the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide User's Guide].<br />
<br />
==Main Sections==<br />
Please [[Special:Userlogin|LOG IN]] before adding/editing pages.<br />
<br />
* [[:Category:Information|Information]]<br />
* [[:Category:Tutorials|Tutorials]]<br />
* [[:Category:Tips|Tips]]<br />
* [[:Category:Security|Security]]<br />
* [[:Category:Hardware|Hardware]]<br />
* [[Links]]<br />
<hr style="width:20em"/><br />
* [[The Regulars|Regulars of Freenode ##slackware]]<br />
* [[Contest|Logo Contest]] (Finished)<br />
<br />
==Thanks==<br />
* '''Anyone who contributes to the wiki :)'''<br />
<br />
==News==<br />
Sorry for the temporary downtime - we forgot to renew the domain name registration. --[[User:rworkman|rworkman]] 0006, 3 November 2009 (UTC)<br />
<br />
There has been a reset of the wiki. The database was corrupted. A few pages, all Talk/Discussion pages and all user accounts were lost. --[[User:Erik|Erik]] 23:44, 6 June 2009 (UTC)<br />
<br />
MediaWiki was upgraded to 1.14.0 --[[User:Erik|Erik]] 16:49, 16 March 2009 (UTC)<br />
<br />
We've moved! We're now hosted by [http://onyxlight.net/ http://onyxlight.net/] with an upgrade to MediaWiki 1.6.6 and<br />
spambot prevention in place. --[[User:Erik|Erik]] 11:33, 22 May 2006 (GMT)<br />
<br />
The contest has been won by [[User:Marcus|Marcus]]. Admire the logo :) --[[User:FredEmmott|FredEmmott]] 12:36, 24 Feb 2005 (GMT)<br />
<br />
Updated SlackWiki to MediaWiki 1.4.7 --[[User:FredEmmott|FredEmmott]] 12:01, 21 Jul 2005 (GMT)<br />
<br />
We're now sharing [http://cardinal.lizella.net cardinal.lizella.net] with several other Slackware projects such as [http://www.slacksec.org SlackSec], the [http://www.slackbook.org Slackware Book Project], and [http://www.slamd64.com Slamd64]. Hopefully this will mean a more reliable and faster wiki --[[User:FredEmmott|FredEmmott]] 19:42, 2 May 2005 (GMT)<br />
<br />
We're back onto my little UML temporarily, but I've finally judged the contest,<br />
congratulations to [[User:Marcus|Marcus]]. Next artwork contest comming soon, please use the [[Talk:Main_Page|main talk page]] for suggestions on more technical contests --[[User:FredEmmott|FredEmmott]] 18:36, 24 Feb 2005 (GMT)<br />
<br />
Thanks to RackSpace and Michael Shuler - they've generously donated a dedicated server to http://www.slacksec.org, which slackwiki is sharing --[[User:FredEmmott|FredEmmott]] 15:06, 1 Dec 2004 (CST)<br />
<br />
We are now sharing this server with http://www.slacksec.info - security updates in Pat's absence --[[User:FredEmmott|FredEmmott]] 22:22, 19 Nov 2004 (GMT)<br />
<br />
We should not have as many problems with server now - I have no choice but to run debian on this server, and apparantly they missed backporting a security patch, so it's now on traditional non-debianified apache 1.3.33 :) --[[User:FredEmmott|FredEmmott]] 18:03, 2 Nov 2004 (GMT)<br />
<br />
Please feel free to bring our old pages over from [http://slackwiki.org/old/index.php?pagename=HomePage the old site] --[[User:FredEmmott|FredEmmott]] 21:23, 31 Oct 2004 (GMT)<br />
<br />
Swapped wiki software again because PHPWiki is too buggy --[[User:FredEmmott|FredEmmott]] 21:11, 31 Oct 2004 (GMT)</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Binary_Numbers&diff=244Binary Numbers2009-08-31T13:40:47Z<p>Rworkman: Fixed some formatting</p>
<hr />
<div>Based on Sandman1's tutorial, with heavy edits and additions by rworkman.<br />
<br />
You probably remember from learning numbers in elementary/primary school how you have the 'ones' place and the 'tens' place and the 'hundreds' place and so on... Let's take the number 4,728 for an example: <br />
<br />
The digit in the 'ones' place is 8<br />
The digit in the 'tens' place is 2<br />
The digit in the 'hundreds' place is 7<br />
The digit in the 'thousands' place is 4<br />
<br />
The ones/tens/hundreds/etcetera come from the fact that in base 10, the digits of a number are laid out like this: <br />
<br />
10^0 = 1 -----> 'ones' place<br />
10^1 = 10 ----> 'tens' place<br />
10^2 = 100 ---> 'hundreds' place<br />
10^3 = 1000 --> 'thousands' place <br />
10^4 = 10000 -> 'ten-thousands' place<br />
and so on...<br />
<br />
So, in the number given above (4,728), we have: <br />
<br />
8 'ones' -------> 8 x 1 = 8<br />
2 'tens' -------> 2 x 10 = 20<br />
7 'hundreds' ---> 7 x 100 = 700<br />
4 'thousands' --> 4 x 1000 = 4000<br />
<br />
Add up these totals:<br />
8 + 20 + 700 + 4000 = 4728<br />
<br />
The Binary Number system works the same way, and is a pretty easy thing to learn, but may be confusing at first. The first thing you need to memorize is 2 raised to the powers, for instance:<br />
2^0 2^1 2^2 2^3 2^4 2^5 2^6 2^7 2^8<br />
1 2 4 8 16 32 64 128 256<br />
<br />
Instead of a 'ones' place, a 'tens' place, a 'hundreds' place, and so on like in base 10, there is a 'ones' place (2^0), and 'twos' place (2^1), a 'fours' place (2^2), an 'eights' place (2^3), and so on...<br />
<br />
Now we first want to be able to take a binary number and turn it into decimal format or base 10. So the first example:<br />
<br />
1 1 1 1<br />
* * * *<br />
8 4 2 1<br />
^ ^ ^ ^<br />
8 + 4 + 2 + 1 = 15<br />
<br />
Now from the example above you see how the 8 is on the left and the 1 is on the right. This will always be that order. You see above that you multiply the 1's with the actual digit it's located in. Now this is all hard to explain so I am going to show you another example: <br />
<br />
1 0 0 0 0<br />
* * * * *<br />
16 8 4 2 1<br />
^ ^ ^ ^ ^<br />
16 +0 + 0 + 0 + 0 = 16<br />
<br />
Now from the example above you see how it is 16 because all of the other placements are 0's and everything multiplied by zero is zero. Now converting from decimal to binary is a bit trickier, here is a simple example:<br />
<br />
20 is the number we will be converting. We first need to find the highest value of the binary numbers above so we can subtract from it. 32 is to high because it is a bigger than 20. So we will use 16. We put a 1 in the 16 place and subtract from 20: <br />
<br />
20 - 16 = 4<br />
<br />
Now the next power is the 2^3 and that is 8. Since 8 is bigger than 4 we can put a zero. So we now are at 22 which is 4. Well, 4 is not bigger than 4 because it is the same number, so we subtract 4 and put a 1 there. <br />
<br />
4 - 4 = 0<br />
<br />
Since we have nothing left we just fill the rest of the placements with zeros: <br />
<br />
10100<br />
<br />
Now you can double check the work and find out that it is 20. Now I will show one more example, this time I will convert 25 to binary. For this example I will start by putting a 1 in the 2^4's place and subtract:<br />
<br />
25 - 16 = 9<br />
<br />
Now we have 9, so we look at the next power and see if it can go into 9. Which the next number is 8 and we can so we put a 1 in the 2^3's place. Now we subtract again: <br />
<br />
9 - 8 = 1<br />
<br />
Now we have 1 left over, now we want to put this in 20's place. So we skip over the 2^2 and 2^1. The reason why we skip this is because 1 cannot go into 4 and 2 equally. Now we have this binary number: <br />
<br />
11001<br />
<br />
This leads to a discussion about ipv4 addressing. An ipv4 address consists of 32 bits. 8 bits = 1 byte ; therefore, an ipv4 address is 4 bytes long. For example, 192.168.10.100 is an ipv4 address. Each byte of the address is separated by a dot (.) - in other words, the first byte (or eight bits) of the address is 192, the next is 168, the next is 10, the last is 100. You're probably wondering where the "eight bits" comes into play, right? :-)<br />
<br />
In binary, 192 = 11000000 and 168=10101000 and 10 = 00001010 and 100 = 01100100 Work it out for yourself (based on the information above) if you don't believe me.<br />
<br />
You've probably seen the CIDR notation before - maybe an address block was written like this: 192.168.10.1/24 What that tells you is that only the first 24 bits of the address are important. That one's easy, as 24 bits equals 3 bytes; therefore, only the first three octets are important. In other words, 192.168.10.1/24 would match any ip address from 192.168.10.1 through 192.186.10.255. That same pattern applies for a netmask of /8, /16, or /32. 192.0.0.0/8 would match any ip address that begins with 192. 192.168.0.0/16 would match any ip address that begins with 192.168. 192.168.10.100/32 will match *only* .100 -- this netmask means that *all* 32 bits are important; they must all match (as opposed to only 8 or 16 or 24 or whatever other number matching).<br />
<br />
So what if the netmask doesn't work out to a nice and easy byte boundary? Well... let's look at our original ip address again. <br />
<br />
192.168.10.100 = 11000000.10101000.00001010.01100100<br />
<br />
Suppose you're given 192.168.10.100/29 and asked to calculate a valid range of ip addresses. This tells you that the first 29 bits are important, but the others can change and still match the netmask. The first 29 bits are: 11000000.10101000.00001010.01100*** The *** represents the three bits that can change. For those three bits, here are your options (I'm leaving a space between the 29th and 30th bit): <br />
<br />
11000000.10101000.00001010.01100 000 = 192.168.10.96<br />
11000000.10101000.00001010.01100 001 = 192.168.10.97<br />
11000000.10101000.00001010.01100 010 = 192.168.10.98<br />
11000000.10101000.00001010.01100 011 = 192.168.10.99<br />
11000000.10101000.00001010.01100 100 = 192.168.10.100<br />
11000000.10101000.00001010.01100 101 = 192.168.10.101<br />
11000000.10101000.00001010.01100 110 = 192.168.10.102<br />
11000000.10101000.00001010.01100 111 = 192.168.10.103<br />
<br />
Typically, this would be denoted as 192.168.10.96/29 The next /29 block would be 192.168.10.104/29, and then 192.168.10.112/29, and so on.<br />
<br />
Hopefully that helped a bit :) --rworkman</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Binary_Numbers&diff=243Binary Numbers2009-08-31T13:39:49Z<p>Rworkman: Initial import from webarchive - how to do exponents?</p>
<hr />
<div>Based on Sandman1's tutorial, with heavy edits and additions by rworkman.<br />
<br />
You probably remember from learning numbers in elementary/primary school how you have the 'ones' place and the 'tens' place and the 'hundreds' place and so on... Let's take the number 4,728 for an example: <br />
<br />
The digit in the 'ones' place is 8<br />
The digit in the 'tens' place is 2<br />
The digit in the 'hundreds' place is 7<br />
The digit in the 'thousands' place is 4<br />
<br />
The ones/tens/hundreds/etcetera come from the fact that in base 10, the digits of a number are laid out like this: <br />
<br />
10^0 = 1 -----> 'ones' place<br />
10^1 = 10 ----> 'tens' place<br />
10^2 = 100 ---> 'hundreds' place<br />
10^3 = 1000 --> 'thousands' place <br />
10^4 = 10000 -> 'ten-thousands' place<br />
and so on...<br />
<br />
So, in the number given above (4,728), we have: <br />
<br />
8 'ones' -------> 8 x 1 = 8<br />
2 'tens' -------> 2 x 10 = 20<br />
7 'hundreds' ---> 7 x 100 = 700<br />
4 'thousands' --> 4 x 1000 = 4000<br />
<br />
Add up these totals:<br />
8 + 20 + 700 + 4000 = 4728<br />
<br />
The Binary Number system works the same way, and is a pretty easy thing to learn, but may be confusing at first. The first thing you need to memorize is 2 raised to the powers, for instance:<br />
2^0 2^1 2^2 2^3 2^4 2^5 2^6 2^7 2^8<br />
1 2 4 8 16 32 64 128 256<br />
<br />
Instead of a 'ones' place, a 'tens' place, a 'hundreds' place, and so on like in base 10, there is a 'ones' place (2^0), and 'twos' place (2^1), a 'fours' place (2^2), an 'eights' place (2^3), and so on...<br />
<br />
Now we first want to be able to take a binary number and turn it into decimal format or base 10. So the first example:<br />
<br />
1 1 1 1<br />
* * * *<br />
8 4 2 1<br />
^ ^ ^ ^<br />
8 + 4 + 2 + 1 = 15<br />
<br />
Now from the example above you see how the 8 is on the left and the 1 is on the right. This will always be that order. You see above that you multiply the 1's with the actual digit it's located in. Now this is all hard to explain so I am going to show you another example: <br />
<br />
1 0 0 0 0<br />
* * * * *<br />
16 8 4 2 1<br />
^ ^ ^ ^ ^<br />
16 +0 + 0 + 0 + 0 = 16<br />
<br />
Now from the example above you see how it is 16 because all of the other placements are 0's and everything multiplied by zero is zero. Now converting from decimal to binary is a bit trickier, here is a simple example:<br />
<br />
20 is the number we will be converting. We first need to find the highest value of the binary numbers above so we can subtract from it. 32 is to high because it is a bigger than 20. So we will use 16. We put a 1 in the 16 place and subtract from 20: <br />
<br />
20 - 16 = 4<br />
<br />
Now the next power is the 2^3 and that is 8. Since 8 is bigger than 4 we can put a zero. So we now are at 22 which is 4. Well, 4 is not bigger than 4 because it is the same number, so we subtract 4 and put a 1 there. <br />
<br />
4 - 4 = 0<br />
<br />
Since we have nothing left we just fill the rest of the placements with zeros: <br />
<br />
10100<br />
<br />
Now you can double check the work and find out that it is 20. Now I will show one more example, this time I will convert 25 to binary. For this example I will start by putting a 1 in the 2^4's place and subtract:<br />
<br />
25 - 16 = 9<br />
<br />
Now we have 9, so we look at the next power and see if it can go into 9. Which the next number is 8 and we can so we put a 1 in the 2^3's place. Now we subtract again: <br />
<br />
9 - 8 = 1<br />
<br />
Now we have 1 left over, now we want to put this in 20's place. So we skip over the 2^2 and 2^1. The reason why we skip this is because 1 cannot go into 4 and 2 equally. Now we have this binary number: <br />
<br />
11001<br />
<br />
This leads to a discussion about ipv4 addressing. An ipv4 address consists of 32 bits. 8 bits = 1 byte ; therefore, an ipv4 address is 4 bytes long. For example, 192.168.10.100 is an ipv4 address. Each byte of the address is separated by a dot (.) - in other words, the first byte (or eight bits) of the address is 192, the next is 168, the next is 10, the last is 100. You're probably wondering where the "eight bits" comes into play, right? :-)<br />
<br />
In binary, 192 = 11000000 and 168=10101000 and 10 = 00001010 and 100 = 01100100 Work it out for yourself (based on the information above) if you don't believe me.<br />
<br />
You've probably seen the CIDR notation before - maybe an address block was written like this: 192.168.10.1/24 What that tells you is that only the first 24 bits of the address are important. That one's easy, as 24 bits equals 3 bytes; therefore, only the first three octets are important. In other words, 192.168.10.1/24 would match any ip address from 192.168.10.1 through 192.186.10.255. That same pattern applies for a netmask of /8, /16, or /32. 192.0.0.0/8 would match any ip address that begins with 192. 192.168.0.0/16 would match any ip address that begins with 192.168. 192.168.10.100/32 will match *only* .100 -- this netmask means that *all* 32 bits are important; they must all match (as opposed to only 8 or 16 or 24 or whatever other number matching).<br />
<br />
So what if the netmask doesn't work out to a nice and easy byte boundary? Well... let's look at our original ip address again. <br />
<br />
192.168.10.100 = 11000000.10101000.00001010.01100100<br />
<br />
Suppose you're given 192.168.10.100/29 and asked to calculate a valid range of ip addresses. This tells you that the first 29 bits are important, but the others can change and still match the netmask. The first 29 bits are: 11000000.10101000.00001010.01100*** The *** represents the three bits that can change. For those three bits, here are your options (I'm leaving a space between the 29th and 30th bit): <br />
<br />
11000000.10101000.00001010.01100 000 = 192.168.10.96<br />
11000000.10101000.00001010.01100 001 = 192.168.10.97<br />
11000000.10101000.00001010.01100 010 = 192.168.10.98<br />
11000000.10101000.00001010.01100 011 = 192.168.10.99<br />
11000000.10101000.00001010.01100 100 = 192.168.10.100<br />
11000000.10101000.00001010.01100 101 = 192.168.10.101<br />
11000000.10101000.00001010.01100 110 = 192.168.10.102<br />
11000000.10101000.00001010.01100 111 = 192.168.10.103<br />
<br />
Typically, this would be denoted as 192.168.10.96/29 The next /29 block would be 192.168.10.104/29, and then 192.168.10.112/29, and so on.<br />
<br />
Hopefully that helped a bit :) --rworkman</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Links&diff=52Links2009-05-29T00:36:32Z<p>Rworkman: Removed one of my links</p>
<hr />
<div>==Slackware Links==<br />
* http://www.slackware.com - the home of Slackware<br />
* http://www.slackwaregallery.com - our ugly mugs :)<br />
* ftp://termserver.niesc.org/pub/sandman1 - Packages mostly by [[User:Sandman1|Sandman1]]<br />
* http://www.chaosbits.net/Articles/Historical/SlackwareFAQ/ - Slackware FAQ by [[User:juhl|juhl]] (Jesper Juhl)<br />
* http://slackware.wordpress.com - Slackware Blog by [[User:Tyler|Tyler]]<br />
* http://www.slackbook.org - updated version of the slackware book<br />
* http://fredemmott.co.uk/rss.php - RSS feeds for slackware 10 patches and the slackware-current ChangeLog<br />
* http://slackware.it/en/rss - RSS feeds for stable Slackware release and -current ChangeLog<br />
* http://userlocal.com/ - A focal point for the online Slackware Linux community<br />
* http://www.slackware.com/getslack - Extensive listing of Slackware mirrors<br />
* http://www.slackbasics.org/ - "Slackware Linux Basics" by Daniel de Kok<br />
* http://uselesstree.org/ - The Complete Slacker<br />
* http://shilo.is-a-geek.com/ - Shilo's tutorial<br />
* http://www.linuxquestions.org/questions/forumdisplay.php?forumid=14 - Slackware forum<br />
* http://www.kde-look.org/content/show.php?content=23384 - Slack-Track - a superkaramba theme to track the slackware-current changelog on your desktop, created by [[User:omal|omal]]<br />
* http://www.slacklife.com.br - Slackware Brazillian Community - by [[User:Redhate|redhate]]<br />
* http://www.slackware-peru.org - Slackware Peruvian Community - by [[User:R1CHARD|R1CHARD]]<br />
* http://slackware.linux.or.id - Indonesian Slackware Community - by [[User:Willysr|Willysr]]<br />
* http://open-eslack.org/ - Spanish Slackware community<br />
* http://sbopkg.org - Sbopkg is a command-line and dialog-based tool to synchronize with the SlackBuilds.org repository<br />
<br />
==General Links==<br />
* http://freshmeat.net - large index of Unix and cross-platform software and themes<br />
* http://sourceforge.net - large repository of Open Source code and applications<br />
* http://developer.berlios.de - another Open Source repository - ideal if you want subversion hosting for your project<br />
* http://art.gnome.org - gnome-desktop themes and backgrounds<br />
* http://www.gnome-look.org - eyecandy for your gnome-desktop<br />
* http://www.kde-look.org - eyecandy for your KDE desktop<br />
* http://www.kde-apps.org - Applications and addons for KDE<br />
* http://kerneltrap.org - Kernel talk<br />
* http://urbanmyth.org/microcode/ - The latest microcode for your Intel CPUs<br />
* http://www.themedepot.org/ - Generalized theme site for X11 based programs<br />
<br />
==Slack==<br />
* http://www.subgenius.com - The [[Church of the SubGenius]]: the source of the term "Slack"<br />
* http://www.modemac.com/x-day - X-Day<br />
* http://en.wikipedia.org/wiki/Church_of_the_SubGenius - Wikipedia entry<br />
<br />
==Free packages==<br />
<br />
<br />
* [http://slackware.com/~alien/ http://slackware.com/~alien/] Eric Hameleers' packages<br />
* [http://rlworkman.net/pkgs/ http://rlworkman.net/pkgs/] rworkman's packages<br />
* http://www.linuxpackages.net/<br />
* [http://www.slacky.eu/repository/slackware-11.0/ Slacky.eu] Italian Slackware site<br />
* [http://www.audioslack.com/packages/ Audioslack.com] Audio software packages<br />
* [http://straterra.info/Packages/ http://straterra.info/Packages/] Straterra's packages<br />
* [http://www.sekurity.com/packages/ Sekurity.com] dadexter's packages<br />
* [http://slacke17.sourceforge.net/ SlackE17] A distribution of Enlightenment DR17 for Slackware<br />
* [http://scxd.info/en/ Slackware Current eXtended Desktop] Packages for Slackware Current<br />
* [ftp://termserver.niesc.org/ ftp://termserver.niesc.org] Sandman1's packages<br />
<br />
==.SlackBuild Repositories==<br />
* http://slackbuilds.org - The SlackBuilds.org Project<br />
* http://slackbuilds.net - The French SlackBuilds Repository<br />
* http://www.slackware.com/~alien/slackbuilds/ - Eric "Alien" Hameleer's SlackBuilds<br />
* http://contrib.slamd64.com - [http://contrib.slamd64.com buildcontrib] can build and fetch these packages for you. Primarily for Slamd64, but work on x86 as well<br />
* http://slackbuild.strangeworlds.co.uk - cathectic's SlackBuilds<br />
* http://buildpkg.berlios.de/ - buildpkg: a Slackware package building utility.<br />
* http://textlinux.slackadelic.com/slackbuilds/ - A repository dedicated to command line (friendly) applications<br />
* http://scxd.info/pub/slackbuilds/ - Slackware Current eXtended Desktop's SlackBuilds<br />
<br />
==Live CD's based on Slackware==<br />
* [http://www.remote-exploit.org/index.php/Main_Page BackTrack] The result of the merging of two Innovative Penetration Testing live Linux distributions: Whax and Auditor<br />
* [http://mutagenix.org Mutagenix] A basic rescue CD and a Freerock GNOME based desktop CD<br />
* [http://www.slax.org Slax Homepage]<br />
* [http://slampp.abangadek.com SLAMPP Homepage]<br />
<br />
==Other Wikis==<br />
* [http://www.slackforum.de/wiki/ A German Slackware Wiki]<br />
* [http://alien.slackbook.org/ Alien Bob's Wiki]<br />
* http://open-eslack.org/wiki/ - Wiki of the Slackware spanish community<br />
* http://slackware.linux.or.id/wiki/ - Indonesian Slackware Wiki</div>Rworkmanhttps://www.slackwiki.com/index.php?title=User:Rworkman&diff=51User:Rworkman2009-05-29T00:21:28Z<p>Rworkman: </p>
<hr />
<div> http://slackware.com/~rworkman/<br />
http://rlworkman.net/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=User:Rworkman&diff=50User:Rworkman2009-05-29T00:20:50Z<p>Rworkman: Added talk page</p>
<hr />
<div>http://slackware.com/~rworkman/<br />
http://rlworkman.net/</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Windows_Partitions&diff=49Windows Partitions2009-05-29T00:19:35Z<p>Rworkman: Moved from old wiki</p>
<hr />
<div>One of the frequent questions on ##slackware is something along the lines of "How can I allow normal users to access my Windows partition?" There are *at least* two different ways of doing this.<br />
<br />
For a FAT partition, you *could* add umask=0000 to /etc/fstab's options, but I personally don't recommend doing that. It's *your* computer, so you make the call, but I would do something along these lines:<br />
1. If you want *every* user to be able to read and write to the partition, then you can add dmask=0000 and fmask=0111 to /etc/fstab's options and be done with it - problem solved.<br />
<br />
/dev/hda1 /mnt/win98 vfat rw,dmask=0000,fmask=0111 0 0<br />
<br />
The reason for dmask/fmask as opposed to umask is quite obvious (though I hadn't thought about it until elohim on ##slackware pointed it out): The FAT and NTFS file systems don't "understand" the executable (-x) bit, so it's automatically present on every file in such a filesystem. There's no need for normal files to be executable (and it can indeed be a security risk), so we use fmask to turn off those permissions.<br />
<br />
2. If you only want some users to be able to read and write to the partition, but you want *every* user to have read access, then you'll want something along these lines. First, create a special group called "windows" (change the name if you wish) by adding it to /etc/group using your favorite editor and add to this group the users you want to have write access. <br />
<br />
nogroup:x:99:<br />
users:x:100:<br />
console:x:101:<br />
windows:x:102:user1,user2,user3<br />
<br />
Next, edit your /etc/fstab line for that partition and specify that it be mounted with group ownership of the "windows" group, and that write access be removed from others.<br />
<br />
/dev/hda1 /mnt/win98 vfat rw,gid=102,dmask=0002,fmask=0113 0 0<br />
<br />
An NTFS partition will be mounted read-only, so you won't have write access for anyone, but the central idea is the same.<br />
<br />
If you don't want everyone else to even have read access to the partition, you can easily do that with the above fstab line modified a bit:<br />
<br />
/dev/hda1 /mnt/winXP ntfs ro,gid=102,dmask=0227,fmask=0337 0 0<br />
<br />
If you prefer write access to the partition, then you can use ntfs-3g instead and something like this:<br />
All users can read the partition; only members of gid 102 can write:<br />
/dev/hda1 /mnt/win98 ntfs-3g rw,gid=102,dmask=0002,fmask=0113 0 0<br />
Users of gid can read and write; nobody else can do anything:<br />
/dev/hda1 /mnt/winXP ntfs-3g rw,gid=102,dmask=0007,fmask=0117 0 0<br />
<br />
For more information, see the [[Permissions and Umasks]] and [[Fstab]] pages.<br />
<br />
--rworkman (thanks to Erik for the pointers about dmask and fmask)<br />
<br />
[[Category:Tutorials]]</div>Rworkmanhttps://www.slackwiki.com/index.php?title=Resource_Limits&diff=48Resource Limits2009-05-29T00:17:30Z<p>Rworkman: Move from old wiki</p>
<hr />
<div>= Purpose =<br />
<br />
This page does not attempt to explain the different types of system resource limits or when it is (or is not) appropriate to change them; see '''man ulimit''' and [[http://google.com Google]] for that discussion.<br />
<br />
However, some users run into problems with the linux kernel's default limit settings, so we'll attempt to explain how to modify them to suit special needs.<br />
<br />
= Overview =<br />
<br />
The default settings provided by the kernel are sane values for most multi-user machines. Issuing the command '''ulimit -Hn''' should show the following:<br />
user@host:~$ ulimit -Hn<br />
1024<br />
and '''ulimit -n''' should show this:<br />
user@host:~$ ulimit -n<br />
1024<br />
<br />
The first command shows the hard limit set by the kernel, and the second command shows the soft limit set by the user. An unprivileged user can increase the soft limit (up to the hard limit value), and he is also able to lower the hard limit (but then is unable to increase it, as an unprivileged user cannot raise the hard limit at all).<br />
<br />
There are some situations which might require a larger hard limit for users, and the obvious "solution" is to add a line in /etc/profile to increase it. However, this will not work, because normal users cannot increase their hard limits (as indicated above).<br />
<br />
= Solution =<br />
<br />
To increase the hard limits for users, you will need to create '''/sbin/initscript''' and place appropriate commands inside it. The easiest way is to copy the file '''/sbin/initscript.sample''' to '''/sbin/initscript''' and edit the copy, but you are certainly free to "roll your own." If you decide to create your own, make sure it is executable or it will not work. <br />
<br />
Using the following '''/sbin/initscript''' file:<br />
<br />
PATH=/bin:/sbin:/usr/bin:/usr/sbin<br />
export PATH<br />
<br />
# Increase the hardlimit for open files<br />
ulimit -Hn 4096<br />
<br />
# Execute the program.<br />
eval exec "$4"<br />
<br />
You should get the following after a reboot:<br />
user@host:~$ ulimit -Hn<br />
4096<br />
<br />
user@host:~$ ulimit -n<br />
1024<br />
<br />
Notice that the hardlimit is now 4096 (as specified in /sbin/initscript), but the softlimit is still 1024. In other words, you will still need to use /etc/profile (or some other shell init file - see below for recommendation) to raise the desired users' softlimits. With some creative scripting, you can be more selective about which users have what limits.<br />
<br />
Rather than editing the system /etc/profile, it's recommended to create a custom file in /etc/profile.d and make it executable. This way, you don't have to worry about trying to merge your changes to /etc/profile when doing Slackware upgrades to new versions.<br />
<br />
= Other Resources =<br />
<br />
* '''man initscript'''<br />
* '''man ulimit'''<br />
<br />
[[Category:Tutorials]]</div>Rworkman