In a previous article I addressed how to compile a kernel for Ubuntu Intrepid using git and in a follow up article I explained how to compile a new release if you already compiled your own custom kernel using git. The upgrade article was written if the kernel upgrade was one where the only ABI number changed was the last one. In this article I’ll explain how you can update your previously compiled custom kernel to a newer version, if you used git. This article won’t touch an upgrade of kernel 2.6.27 to 2.6.28.
Updates: Jan 9, 2009: Added git add to the “commit your changes” section.
The base of this article is that you already compiled a your own kernel with git using my previous article.
A lot of the steps are similar to my previous article but there are a few extra steps and liek I mentioned earlier I also explain how to handle the situation where the Ubuntu git repository is already in the next development cycle.
On October 31st, 2008 I have a made a few changes in the article, Compiling a custom kernel for Ubuntu Intrepid using git, to help compiling an upgrade of the kernel a bit easier. If you compiled a kernel prior to this you need to follow the steps in Preparing manual upgrade otherwise you can skip this step and go straight to Upgrading the source. If you read this article to update your kernel again you can also go straight to Upgrading the source.
Preparing manual upgrade
We need to work in our created branch
git checkout core2
We’re going to copy all the files we needed to change, restore the branch to it’s original starting point and copy all of our files back again. To keep remember this state we’ll do a commit.
We now have the latest kernel source but we don’t want to the updates that are part of the next release. To check for the latest tagged version the easiest way is to check the debian changelog.
less debian/changelog
Look for the second section of the changelog
linux (2.6.27-10.21) UNRELEASED; urgency=low
CHANGELOG: Do not edit directly. Autogenerated at release. CHANGELOG: Use the printchanges target to see the curent changes. CHANGELOG: Use the insertchanges target to create the final log.
-- Tim Gardner Mon, 24 Nov 200810:50:51-0700
linux (2.6.27-10.20) intrepid-proposed; urgency=low
In this case the latest tagged version is 2.6.27-10.20 Let’s find the git tag name for this version
git tag -l*2.6.27-10.20*
This will result in
Ubuntu-2.6.27-10.20
We want to reset our git repository to this state, as we don’t want the unreleased updates
git reset Ubuntu-2.6.27-10.20--hard
To check if the above command really worked
git log
And log should say:
UBUNTU: Ubuntu-2.6.27-10.20
Now that the master branch is all set we can go into our core branch and get ready for compilation.
We need to edit the control file debian/control. In the sections of core2 we created we need to change all the references to -7 to -10. I usually do it using vi, search for -7 and manually replacing it with -10.
Now we need to commit our changes in the git repository
git add. git commit -a-m"Core2 modifications"
The text after -m is the message you add to your commit.
Có nhiều cách cài một distro linux từ usb ,nhưng ở đây tôi xin giới thiệu một cách cài debian từ usb
Bước 1 : Chuẩn bị -Bios có hỗ trợ boot từ USB -Một usb cỡ 1G trở lên -File cài debian lenny hỗ trợ cài đặt qua USB , bản cho AMD64 có thể download ở đây ,bản cho i386 ở đây -Một máy có cài sẵn linux
Bước 2 : Chuẩn bị USB cài đặt debian lenny -Copy file img ra usb
dd if=debian-eeepc.img of=/dev/sdb sync
Xong! Bây giờ bạn chỉ việc boot lại từ usb và cài đặt
The core of PolicyKit is implemented as a shared library that Mechanisms can link to and use as the decider component. There's a small set of (extensible) data structures that establish a vocabulary for libpolkit and the Mechanism to describe the Subject and Action in question. The Mechanism should think about libpolkit as a black box; it's sole purpose is to answer whether a given Subject is permitted to do a specific Action. The answer, obviously, comes from a configuration source read by the library and maintained by the system administrator; see PolicyKit configuration for details on PolicyKit configuration.
The answer from libpolkit is not limited to a boolean value; essentially the following values can be returned
*
Yes: It is ok for the Mechanism to carry out the Action requsted by the given Subject. *
No: The Mechanism should not carry out the Action requested by the given Subject. *
Require authentication: The Subject (e.g. the UI application) needs to ask the user to authenticate in order for the Mechanism to carry out this Action.
In addition,
*
Authentication can be specified (in the return value from libpolkit) as either user authentication (user puts in his own password) or super user authentication (user puts in the root password or a user in an administrator group authenticates). *
The authorization can be kept (this is also specified in the return value from libpolkit) either 1) indefinitely (e.g. it persists across reboots and different desktop sessions); 2) for the remainder of the desktop session the Subject is part of; or 3) confined to the process life-time of the Subject.
To facilitate the authentication step, there's a shared library called libpolkit-grant. Given an Action, this library uses a privileged helper (as in it's a setgid polkit application) to authenticate the user (using PAM) and upon successful authentication leave a cookie specifying that the given Action can be carried out. It is the presence and contents of this cookie that will allow libpolkit to return Yes when the Subject asks the Mechanism to carry out the Action again. This whole process is best explained by a diagram:
Detail on the diagram:
1.
The user double clicks an icon on the desktop that resembles a hard drive. As mounting file systems is a privileged operation, the File Manager calls, via the system message bus, into the Mechanism (HAL). 2.
The Mechanism identifies the caller, using ConsoleKit, all the relevant information about the caller and stores this information in a PolKitCaller object. This information includes *
UNIX user id (uid) *
UNIX process id (pid) *
An identifier for the desktop session and whether the session is active (e.g. currently showing on a display), whether it's local and if it's remote, the address of the remote display *
Optional OS specific attributes such as the SELinux security context.
Second, the Mechanism creates a PolKitAction object that represents the action that the caller wants the Mechanism to perform on it's behalf. Specifically, for HAL, the D-Bus method call Mount() maps into two actions: org.freedesktop.hal.storage.mount-fixed and org.freedesktop.hal.storage.mount-removable. As the device the user wants to mount is an internal hard disk, HAL picks org.freedesktop.hal.storage.mount-fixed and constructs the PolKitAction object.
Third, HAL now calls the polkit_context_can_caller_do_action() function in libpolkit and passes the PolKitAction and PolKitCaller objects as parameters. Armed with all this information, libpolkit is now in a position to make a decision; see PolicyKit configuration for how exactly this is done.
The result from libpolkit is of the type PolKitResult and tells whether the given caller is allowed to do the given action. If the result is yes (e.g. POLKIT_RESULT_YES), the Mechanism carries out the action on behalf of the caller. 3.
If the result from libpolkit is not yes, the Mechanism sends a reply back to the caller with two pieces of information: *
The result from libpolkit itself. *
The action that the caller needs to be authorized to do.
For this example, HAL returns an exception via D-Bus with the name org.freedesktop.Hal.Device.PermissionDeniedByPolicy and the detail text string "org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always" (assuming the return code was POLKIT_RESULT_AUTH_ADMIN_KEEP_ALWAYS). This enables the caller to take action and acquire authorization to do this action. 4.
The File Manager receives the exception from the Mechanism and since the exception name org.freedesktop.Hal.Device.PermissionDeniedByPolicy is well-defined it decodes the exception detail string to learn that in order to do what the user asked it (by double clicking an icon resembling a hard drive), it needs to make the user authenticate as an administrator in order to be authorized for the action org.freedesktop.hal.storage.mount-fixed.
The File Manager now proceeds to call into an Authentication Agent and passes two items of information *
The PolKitResult that libpolkit returned to the Mechanism and passed on to the File Manager. *
The PolKitAction that libpolkit returned to the Mechanism and passed on to the File Manager.
In fact, the File Manager could implement an Authentication Agent by itself but for both practical reasons (implementing an Authentication Agent is not trivial) and security reasons (it is typically a good idea to have password handling in as few processes as possible) it is preferable to have this done in a separate process. PolicyKit defines an abstract interface to interact with the an Authentication Agent, see the Authentication Agent section for details. For details on the Authentication Agent for the GNOME desktop, please see the PolicyKit-gnome documentation. 5.
The first thing that the Authentication Agent does when it receives a request from an application is to validate the incoming parameters to see if they are correct; essentially it's doing exactly the same check as the Mechanism was doing in step 2; e.g. constructing PolKitCaller and PolKitAction objects, calling into polkit_context_can_caller_do_action() and examining the returned PolKitResult.
If the parameters check out, the Authentication Agent now pops up a window to explain the user than authentication is required to perform the desired action. Note that the text to put in the dialog stems from files that are not under the users control (see the section called “Declaring Actions” for details) so there is no chance for any application to spoof the dialog to trick the user into agreeing to authenticate for something while in fact the authentication is about something else.
Internally the Authentication Agent uses services provided by the PolKitGrant class and is little more than a thin layer above the PAM user API. The authentication itself is performed in a privileged helper program (e.g. running with setgid privileges) that communicates with the (graphical) Authentication Agent through pipes. As such, if the user successfully authenticates, the privileged helper program writes an entry into the Authorization Database (it can do so only because it is privileged). When the user is done with the dialog (either through successful authentication or by cancelling) a reply including whether the authorization was gained is sent back to the File Manager
As mentioned, an authorization has a notion of scope which is indicated in the PolKitResult value from libpolkit. The user, when authenticating, can also opt to lessen the scope (e.g. keep the authorization only for the remainder of his desktop session instead of forever) (see this section for details) but he can never widen it - this is checked and enforced by the privileged helper program. The way the authorization is stored is as follows: *
For POLKIT_RESULT_AUTH_[SELF|ADMIN] the authorization is limited to the requesting process; in this example it would be the File Manager. Thus, the UNIX process id (and start time of the process to avoid clashes caused by pid recycling) is used as the primary key in the Authorization Database. Entries like these are flushed when the system is restarted. *
For POLKIT_RESULT_AUTH_[SELF|ADMIN]_KEEP_SESSION the authorization is limited to processes in the same desktop session as the calling process (e.g. the File Manager). The ConsoleKit session identifier is used as the the primary key in the Authorization Database. Entries like these are also flushed when the system is restarted. *
For POLKIT_RESULT_AUTH_[SELF|ADMIN]_KEEP_ALWAYS the authorization is limited to processes owned by the same user as the calling process (e.g. the File Manager). The UNIX uid of the user is used as the the primary key in the Authorization Database. These entries are not flushed when the system is restarted.
6.
If the File Manager is told by the Authentication Agent that the authorization for it to do the action org.freedesktop.hal.storage.mount-fixed was obtained (because the user successfully authenticated), it asks the Mechanism (HAL to perform the action again. This time, because an entry now exists in the Authorization Database, the Mechanism (HAL) will receive the answer POLKIT_RESULT_YES from libpolkit and carry out the action on behalf of the File Manager.
Furthermore, as hinted above, any program can check, using libpolkit, whether a given caller is authorized to do a specific Action (though users may be limited to asking questions only about themselves; not about other users). This is a feature, not a bug, as it allows to build user interfaces where it's possible to use this information to aid the user in carrying out work.
For example, the UI configuration dialog for the desktop clock may provide a button for reconfiguring the system time (which is a privileged operation). Using libpolkit, the desktop code can determine, in advance, if the user is authorized to do the Action org.gnome.clockapplet.mechanism.settime. If the user is authorized, the desktop will paint an ordinary button "Set System Time", if authentication is required, it can paint another button "[L] Set System Time..." where the L is an icon depicting a closed padlock and if the answer is POLKIT_RESULT_NO it can make the button insensitive so it can't be clicked. In fact, the aforementioned PolicyKit-gnome library, provides exactly such services for GTK+ applications.
In order to keep the PolicyKit model reasonably simple, there is no representation of the Object. Instead, a Mechanism that cares about Objects (and many don't; for example, Mechanisms to change the timezone, punch a hole in the firewall or add a user all operate on a singleton Object: the system as a whole) must instead divide a given Action into multiple sub-Actions depending on the nature of the Object.
For example, consider a Mechanism for dial-up networking. Here, the Subject is a UI applet running in a desktop session, the Object is the phone number to dial and the Action is to establish the connection (another Action could be to hang-up an existing connection). Suppose that the Mechanism has a white-list of phone numbers that are trusted; this could simply be a directory /var/lib/dialup-helper/trusted-dialup.d where the system administrator can drop simple text or XML files with phone numbers that are considered safe to dial. If the phone number given by the client matches this white-list, the Mechanism chooses the Action to be dialup-connect-trusted. If it's not in the white-list, the Action will be dialup-connect-untrusted. Hence, depending on how PolicyKit is configured it may return different answers since these are different Actions; one sensible thing in a default desktop rollout would be to always allow the Action dialup-connect-trusted for local active sessions and always require authentication for the Action dialup-connect-untrusted.
By Adam Williamson at http://www.happyassassin.net
Well, I woke up this morning and the site wasn’t working, which isn’t good! So I did a quick fix (gave it an extra 128MB of RAM in VMware and turned on wp-super-cache) and started looking into hosting options. That’s going to be a fun area to get into. Sigh. Still, seems to be holding up so far.
After that I did the forums, and took care of things arising from there. I backported the latest x11-driver-video-intel to 2008 Spring as well (after doing it for 2009, see yesterday). Prompted by this thread, I took a deeper look at what the heck PolicyKit does, exactly, and what’s going wrong in this case, which has been reported by several people.
The symptom is that, if you have a partition on an internal drive that isn’t automatically mounted at boot, it will be shown in Dolphin’s sidebar, but trying to click on it will give you an error message at the bottom of the Dolphin window, saying: “An error occurred while accessing ‘(thepartition)’. the system responded: org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, result)"
Cryptic, much? :)
Well, here's what's going on here. PolicyKit is essentially a generic system for restricting access to actions by users. It lets developers specify that a certain action can only be performed by certain users, or only with admin privileges, or only when a user is active, or only when a user is logged in to a local console, or a combination of the above (for instance, only the user adamw can perform the action, and only when he's logged in locally). Technically speaking PolicyKit has all sorts of advantages over the old, rather hackish frameworks like 'just run stuff as root via gksu or kdesu', console-helper, and things like that. Firstly, it's much more fine-grained, and secondly, it separates out the actual actions that require raised privileges. So it allows, say, a partition management application to be run by a regular user, and then ask for root privileges only if it needs them to alter the partition table. And only that specific action would be done with root privileges: the rest of the application continues to run unprivileged. This has obvious big security benefits over running the entire thing as root.
So, PolicyKit is shiny and useful. But, in this case, it's tripping us up. Why? Well, let's look at the message in more detail:
PermissionDeniedByPolicy is why it won’t mount: it’s telling us PolicyKit isn’t letting us. What ultimately happened is Dolphin asked HAL to mount the device, and it refused, because HAL is now integrated with PolicyKit. Why doesn’t it let us? Well, org.freedesktop.hal.storage.mount-fixed is the specific PolicyKit ‘action’ that’s failing here. That’s the action for mounting a fixed storage device - that is, a permanent storage device, like an internal hard disk partition. The counterpart is a removable storage device, like a USB key. And, finally, auth_admin_keep_always is the access policy granted to the current user. What auth_admin_keep_always means is ‘allow this user to perform the action, but only after authenticating for admin privileges. But once the user has authenticated once, remember that authentication for the rest of this session.’
So, PolicyKit is set to allow regular users to mount fixed partitions, but only if they give the root password first. Why does Dolphin just fall over, instead of asking for the root password? That would be because Dolphin does not, yet, have PolicyKit integration - so it doesn’t know that, in this case, it should call the helper provided by PolicyKit-kde to ask the user to authenticate as root. Since it doesn’t do that, PolicyKit knows the root authentication wasn’t performed, and refuses permission to mount the partition.
So THAT is why you can’t mount an internal drive partition via Dolphin in KDE 4 on Mandriva 2009 (and any other distribution where this is PolicyKit’s default configuration). Whew. What’s to be done?
I filed a bug with KDE about this issue. It has been accepted by one of the lead Dolphin developers, Peter Penz, so hopefully it will be worked on and we’ll be able to integrate this into Dolphin before 2009 Spring comes out. I let our KDE team know about the issue, so they can monitor it. If integration for Dolphin is not forthcoming, we could adjust the default policy in KDE to allow users to mount partitions without authentication, but of course that would be rather less secure.
What can you do if you’re annoyed by this bug (or a similar one) and can’t wait for a fix (or a new distribution release) to show up? Change the policy, of course! There are two GUI frontends for PolicyKit: policykit-gnome and policykit-kde. The policykit-kde shipped in 2009 was rather broken. However, as part of my investigation of this issue, I realized that problem, and updated the Cooker package to the latest SVN revision, which works a lot better. So I’ve also sent that package to 2009 /contrib/backports. I haven’t tested it on 2009, but it ought to work okay, the PolicyKit API is quite stable. So, install that package, and run the KDE Control Center. Go to the Advanced tab, and click on PolicyKit Authorization. Here, you can see all the different sets of actions which PolicyKit controls access to. The one we’re interested in is org.freedesktop.hal, so expand that entry.
Click on “Mount file systems from internal drives.” You’ll see, underneath, the real action name, which we saw in the error message earlier: org.freedesktop.hal.storage.mount-fixed. In theory you should be able to just set the Anyone: drop-down box to Yes, but that didn’t work for me: I think there’s an issue with the resolution of user names. So, instead, create an explicit authorization. Click the ‘Grant’ button, next to Explicit Authorizations. Check the ‘Show system users’ box (this shouldn’t be necessary, and I think it’s related to the ‘Anyone’ bug), and then select your username from the drop-down box (mine was right at the bottom). You can set a constraint, or not, as you choose (it’s probably safest to set ‘Must be in active session on local console’). Then click ‘Grant’. Now you can quit the Control Center, run Dolphin, and click on your partition - and it should mount. There, wasn’t that simple?!
PolicyKit is actually developing into a very powerful framework and will likely be used extensively by many applications in future, and you will be able to use it as a very sophisticated lockdown tool to control how much access users have to different actions on your system.
After that, I also bumped the kde4-extragear-sysadmin package I maintain (which provides the kiosktool and partitionmanager apps, for KDE 4) to the latest SVN, since this whole PolicyKit thing reminded me about it. I also sent Isomaster 1.3.5 to /contrib/backports for 2008 Spring and 2009; thanks to Jerome Soyer for doing the version bump.
Finally, I worked on packaging Navit, a driving navigation application, which was requested by Adam Pigg. With a few patches here and there I’ve got it properly built, but it’s got a bit of an ugly system for configuration (you have to hand-edit a .xml file) and, despite downloading and plugging in a Canadian map file, I couldn’t get it to display anything but a blank orange screen. I’m not sure if this is related to my lack of a GPS device, or just Cooker weirdness, or something else. So I sent the current package to Adam to see whether he can get the app going, since he really has a GPS system. If we can get it going, it’ll be uploaded to Cooker, 2009 and 2008 Spring.
By Matthew Danish ================= Common APT usage apt-get install Downloads and all of its dependencies, and installs or upgrades them. This will also take a package off of hold if it was put on. See below for more info on hold.
apt-get remove [--purge] Removes and any packages that depend on it. --purge specifies that packages should be purged, see dpkg -P for more information.
apt-get update Updates packages listings from Debian mirrors, should be run at least once a day if you install anything that day, and every time after /etc/apt/sources.list is changed.
apt-get upgrade [-u] Upgrades all packages installed to newest versions available. Will not install new or remove old packages. If a package changes dependencies and requires installation of a new package, it will not be upgraded, it will be put on hold instead. apt-get upgrade will not upgrade packages put on hold (that is the meaning of hold). See below for how to manually put packages on hold. I suggest the `-u' option as well, because then you can see what packages are going to be upgraded.
apt-get dist-upgrade [-u] Similar to apt-get upgrade, except that dist-upgrade will install or remove packages to satisfy dependencies.
apt-cache search Searches packages and descriptions for .
apt-cache show Shows the full description of .
apt-cache showpkg Shows a lot more detail about , and its relationships to other packages.
dselect console-apt aptitude gnome-apt Graphical front ends to APT (some of these may be in their own package, that must be installed before use). While dselect is arguably the most powerful, it's also the oldest and hardest to use.
Common Dpkg usage dpkg -i Installs a Debian package file; one that you downloaded manually, for example.
dpkg -c Lists the contents of , a .deb file.
dpkg -I Extracts package information from , a .deb file.
dpkg -r Removes an installed package named
dpkg -P Purges an installed package named . The difference between remove and purge is that while remove only deletes data and executables, purge also deletes all configuration files in addition.
dpkg -L Gives a listing of all the files installed by . See also dpkg -c for checking the contents of a .deb file.
dpkg -s Shows information on the installed package . See also apt-cache show for viewing package information in the Debian archive and dpkg -I for viewing package information extracted from a .deb file.
dpkg-reconfigure Reconfigures an installed package, if it uses debconf (debconf provides that consistent configuration interface for package installation). You can reconfigure debconf itself if you want to change the front-end or priority of questions asked. For example, to reconfigure debconf with the dialog front-end, you simply run:
dpkg-reconfigure --frontend=dialog debconf
echo `` hold'' | dpkg --set-selections Put on hold (command line method)
dpkg --get-selections ``'' Get the current status of (command line method)
dpkg -S Searches for in package database, telling you which packages have that file in them.
Building Debian packages from Source apt-get source [-b] Download the source Debian package for and extract it. You must have deb-src lines in your /etc/apt/sources.list for this to work. If you supply the `-b' option and you are currently root, then the package will be automatically built if possible.
apt-get build-dep Download and install the packages necessary to build the source Debian package . This feature is only present in apt version 0.5 and up. Currently this means that woody and above contain this functionality. If you have an older version of apt then the easiest way to find out the build dependencies is to look in the debian/control file in the source package directory. A common usage of this command is in conjunction with apt-get source -b. For example (as root):
apt-get build-dep apt-get source -b
Will download the source package, all of its build dependencies, and attempt to compile the source package.
dpkg-source -x If you have downloaded the source package for a program manually, which includes several files such as a .orig.tar.gz (or .tar.gz if it is Debian native), a .dsc, and a .diff.gz (if it is not Debian native), then you can unpack the source package using this command on the .dsc file.
dpkg-buildpackage Builds a Debian package from a Debian source tree. You must be in the main directory of the source tree for this to work. Sample usage:
dpkg-buildpackage -rfakeroot -uc -b
Where `-rfakeroot' instructs it to use the fakeroot program to simulate root privileges (for ownership purposes), `-uc' stands for ``Don't cryptographically sign the changelog'', and `-b' stands for ``Build the binary package only''
debuild A handy wrapper script around dpkg-buildpackage that will automatically take care of using fakeroot or not, as well as running lintian and gpg for you.
Fixing dependencies dpkg --configure --pending If dpkg quits with an error while apt-get install, upgrade, or dist-upgradeing try running this to configure the packages that were already unpacked. Then try apt-get install, upgrade, or dist-upgrade -f, and then try apt-get install, upgrade, or dist-upgrade again. Repeat as needed. This usually resolves most dependency problems (also, if it mentions a specific package for some reason, you might want to try installing or removing that package)
apt-get install -f apt-get upgrade -f apt-get dist-upgrade -f Attempt to fix dependencies while doing one of the above. Note that apt-get install -f does not require a argument.
There are tools available to allow anyone to create and distribute a completely customized Ubuntu Based distribution using the Gnome Desktop. Many Kubuntu users would like to do the same thing but such tools are not fully compatible with KDE and the Kiosk tool does not change or remove all of the Kubuntu defaults so that a program like Remastersys can create a customized ISO with the defined changes.
This How To is designed to address these issues and allow those interested in creating their own customized distribution based on Kubuntu. Many thanks to Jamie “Boo” Birse from LinuxMint for giving me a copy of his developer notes, which without, this how to could not have been created. “Boo” is the KDE Guru at LinuxMint and is responsible for the KDE Community Editions. Because The LinuxMint KDE CE distribution is based on Kubuntu his developer notes were extremely helpful.
Getting A Leaner And Cleaner KDE Installed:
The main issue of trying to get a customized KDE Kubuntu based distribution is dealing with many of the hidden default settings in Kubuntu to begin with. Ideally it would be much easier to have a base KDE install where those defaults are not present. Fortunately there is a way to do this using the Ubuntu Repositories.
Step One: Install Ubuntu Server
Normally when you install Kubuntu you download one of the Kubuntu ISO images and make the CD and then install it on the system. However, whether you use the Live CD, or the Alternate Install CD you are going to end up with the default setting we don't want.
In order to avoid getting those configuration files installed one needs to do the installation through another method. That method is to simply use the Ubuntu Server Edition CD instead. The server Edition does not install the X-Server and therefore does not install a GUI. Because of this we can install KDE clean and without the messy Kubuntu default settings.
Download the Ubuntu Server Edition ISO file and create the CD from the image. On the selected machine install the Ubuntu Server. When asked what additional services you wish to install do not select any. This will install only the core Ubuntu components and base files on the system.
Step Two: Update the Installation
sudo apt-get update
sudo apt-get upgrade -y
Step Three: Install X-Server, KDM, KDE-Core Pmount and Synaptic
Obviously we need to install the X-Server and KDE. However, it has to be done correctly or we may as well have used the Kubuntu CDs. Since we only have a command line at this point we will have to utilize it. Login and at the prompt and type the following command EXACTLY as I have it here;
After the installation completes run the following command:
sudo shutdown -r now
Step Four: Use Synaptic To Install Core Software
Add the following to your sources.list file:
## Remastersys
deb http://www.remastersys.klikit.com/repository/ remastersys/
We need some software installed to handle key factors like sound automount and many other things. The current installation is exremely minimal and would require a great amount of time to go through and individually find all the correct packages needed. So I have used Synaptic to create a recovery file of all the software you need for your core install system.
Click Reload in Synaptic to update the apt sources.
In Synaptic go to File >> Read Markings >> browse to the file BaseBuild that was included in the archive along with this file.
Click Apply.
Step Five: Remove the Server Kernel
There is one thing we have to clean up when using this install method, and that is the kernel. Since we used the server edition for the base install we have the server kernel. As we are either building a Desktop System, or a Demonstration System (as is the case with me) we certainly don't need the server kernel.
The corepackages file installed the 2.4.26-18-generic kernel packages (latest at time of this how to) so use synaptic to remove all of the old 2.4.6-xx-server kernel packages on your machine. (Use Completely Remove option to purge them.)
Step Six: Install Additional Packages
NOTE: You may want to use Remastersys to create a core system ISO image before installing more packages. This will allow you to have a clean base install to work from if you want to create different types of Kubuntu Based Distributions.
At this point I am going to let you play on your own. We are going to install the software packages we want to be included on our CD/DVD ISO image. It is completely your choice of what to install. You know what you want to have on your live CD/DVD. There is one important note about what you install though. DO NOT INSTALL ANY PACKAGE THAT WILL SETUP THE KUBUNTU DEFAULTS. If you do then the rest of this How To will become useless for use as I am basing it on a build that is free of these default settings.
Final word of warning, be careful on what you include in your customized distribution. Especially if you include non-open source packages. Some of these by their license must be installed separately by the end user. Also note, even including some open source packages may prove an issue because of some legal restrictions. If you are not sure about some things research, ask in a forum, ask those who also make distributions, etcetera. Do not land yourself in hot water for illegal distribution of software.
Finally to assist you here is a copy of my sources.list file:
# deb cdrom:[Kubuntu 8.04 _Hardy Heron_ - Release i386 (20080423)]/ hardy main restricted
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://us.archive.ubuntu.com/ubuntu/ hardy main restricted
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy main restricted
## Major bug fix updates produced after the final release of the
## distribution.
deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## universe WILL NOT receive any review or updates from the Ubuntu security
## team.
deb http://us.archive.ubuntu.com/ubuntu/ hardy universe
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy universe
deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates universe
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-updates universe
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://us.archive.ubuntu.com/ubuntu/ hardy multiverse
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy multiverse
deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-updates multiverse
## Uncomment the following two lines to add software from the 'backports'
## repository.
## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://us.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
# deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-backports main restricted universe multiverse
## Uncomment the following two lines to add software from Canonical's
## 'partner' repository. This software is not part of Ubuntu, but is
## offered by Canonical and the respective vendors as a service to Ubuntu
## users.
deb http://archive.canonical.com/ubuntu/ hardy partner
# deb-src http://archive.canonical.com/ubuntu/ hardy partner
deb http://security.ubuntu.com/ubuntu/ hardy-security main restricted
# deb-src http://security.ubuntu.com/ubuntu/ hardy-security main restricted
deb http://security.ubuntu.com/ubuntu/ hardy-security universe
# deb-src http://security.ubuntu.com/ubuntu/ hardy-security universe
deb http://security.ubuntu.com/ubuntu/ hardy-security multiverse
# deb-src http://security.ubuntu.com/ubuntu/ hardy-security multiverse
## Linux Mint Elyssa Repositories
deb http://packages.linuxmint.com/ elyssa main upstream import
# deb-src http://packages.linuxmint.com/ elyssa main upstream import
deb http://packages.linuxmint.com/ elyssa community
# deb-src http://packages.linuxmint.com/ elyssa community
deb http://packages.linuxmint.com/ elyssa backport
# deb-src http://packages.linuxmint.com/ elyssa backport
## Medibuntu
deb http://packages.medibuntu.org/ hardy free non-free
## Bleeding Edge Wine Packages
## GPG Add Key Command: wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -
deb http://wine.budgetdedicated.com/apt/ hardy main
# deb-src http://wine.budgetdedicated.com/apt/ hardy main
## Remastersys
deb http://www.remastersys.klikit-linux.com/repository/ remastersys/
There is a known problem in Hardy Heron, Kaffeine is broken and will not function fully. It is best to not include it until it is fixed. If you have it installed you should purge all kaffeine files from your system or you will have issues. (This will be updated when kaffeine is fixed.)
Step Seven: Create A Test Account To See Your Default Setting Changes
Use your current account as the working account where we do all the changes, editing and configuration changes. You will also need a test account to see how things come together as you do them. Test often (you should test each time you make a change to the default desk configuration) and make sure everything is coming together as you planned. Each time you make a change use Krusader or some other File manager in root mode and clean out the entire home folder (including the hidden folders, especially) of your test account. When you do that it will repopulate with new default folders and when you log into it will be as if you logged in for the first time. The reasoning and purpose of this is so we can see what a new user will experience when they use the Live CD/DVD for the first time. Since our global settings will only affect a new user we must make KDE think your test account has never been logged into before each time we use it.
Your initial desktop should look nothing like a standard Kubuntu desktop. Which is good because we can now modify it in any manner we choose. The following steps will take you from this to your final layout step by step. In some cases I will tell you to hand edit the files and in others I will have you use the Kiosk Admin Tool. There are some cases where you can use either method, and I will mention that. However, based on my experiences while putting this How To together I will emphasize what I feel is the better method of the two.
Step Eight: Set Default Kicker Options
NOTE: If you plan on using kicker_kickoff_1, or any other menu system outside of the standard KDE Menu, in your distribution install it now before continuing with the rest of this step. Make sure all panel applets you wish to use are also installed.
Most everything we want to do with the kicker panel needs to be done via the Kiosk Admin Tool. The final part of this step will require the hand editing of a file. You will see and understand why when we get to that.
Start by opening the Kiosk Admin Tool. You will find it under 'System' in the programs section of the KDE Menu.
The default profile should be the only one listed and highlighted. Click on 'Setup Profile' to start. Then click 'Panel' you will get a notice click 'OK' to continue. Click 'Setup Panel' to begin configuring the Global default settings of the kicker panel. Just as if you were on your own desktop right click on kicker to bring up the options. Start with 'Configure Panel' Here you can set the panel looks and operations. When you are all done setting up the panel use the 'Add Applet to Panel” to select what Applets you want starting up and arrange them on the panel where you want. Go back to 'Configure Panel' to make any final adjustments. When done with that click on 'Save' in Kiosk Admin Tool to save your changes. Now use the following command to do a bit of hand editing to your default settings;
kdesu kate /etc/kde-profile/default/share/config/kickerrc
Look at the line labled UntrustedApplets= and see what's listed there. If any applet you have previously selected is listed there then remove it from this line.
Step Nine: Select Your Default Cursor Theme
Setting of the default cursor is much easier now. First make sure that you have installed the cursor theme you wish to use as the default.
The following information is from Debian Admin.
If you want to change the default cursor theme first you need to install one of the available cursor themes:
This will complete the installation. Now you need to run the update-alternative to set/change the current cursor-theme, when prompted give the number of the theme and press enter.
sudo update-alternatives --config x-cursor-theme
There are 24 alternatives which provide `x-cursor-theme’.
Selection Alternative
———————————————–
1 /etc/X11/cursors/core.theme
2 /etc/X11/cursors/redglass.theme
3 /etc/X11/cursors/whiteglass.theme
4 /etc/X11/cursors/handhelds.theme
+ 5 /etc/X11/cursors/crystalblue_classic.theme
6 /etc/X11/cursors/crystalblue_nonanim.theme
7 /etc/X11/cursors/crystalblueleft.theme
8 /etc/X11/cursors/crystalblueleft_classic.theme
9 /etc/X11/cursors/crystalblueleft_nonanim.theme
10 /etc/X11/cursors/crystalgray.theme
11 /etc/X11/cursors/crystalgray_nonanim.theme
12 /etc/X11/cursors/crystalgrayleft.theme
13 /etc/X11/cursors/crystalgrayleft_nonanim.theme
14 /etc/X11/cursors/crystalgreen.theme
15 /etc/X11/cursors/crystalgreen_classic.theme
16 /etc/X11/cursors/crystalgreen_nonanim.theme
17 /etc/X11/cursors/crystalgreenleft.theme
18 /etc/X11/cursors/crystalgreenleft_classic.theme
19 /etc/X11/cursors/crystalgreenleft_nonanim.theme
20 /etc/X11/cursors/crystalwhite.theme
21 /etc/X11/cursors/crystalwhite_nonanim.theme
* 22 /etc/X11/cursors/crystalwhiteleft.theme
23 /etc/X11/cursors/crystalwhiteleft_nonanim.theme
24 /etc/X11/cursors/crystalblue.theme
Press enter to keep the default[*], or type selection number:23 Using ‘/etc/X11/cursors/crystalwhiteleft_nonanim.theme’ to provide ‘x-cursor-theme’
Step Ten: Setup the Desired Default Desktop Icons
To setup default Desktop Icons (The icons every new user will see when they first login) simply setup icons on your working desktop, use the Kiosk Admin Tool and click on 'Setup Profile' Select 'Desktop Icons' and click 'Setup Desktop Icons' then click 'Save'. This will create the file structure the default profile will use to set the default settings. Using Krusader (or some other file manager) in root mode copy the files from your working desktop directory to /etc/kde-profile/default/share/apps/kdedesktop (or kdesktop)/Desktop/
If you want functional Icons for System, Home and Trash then simply cut and paste each of the following into new text files on your desktop to create them. Each one should have its own file and it should be named appropriately:
Once the above files are created then copy them to the afore mentioned directory. Once copied all new (first time) users will get the Icons for System, Home and Trash on their desktop.
NOTE: I recommend you at least put the Trash Icon on new desktops.
Step Eleven: Set the Default Icon Theme
To set default Icons in KDE so that all new (first time users) start with your selected Icon Theme right click on the desktop and select run command. Enter the following into the dialog box:
Kiosk Admin Tool will also do this but its a bit more time consuming.
Step Thirteen: Set the Default Theme and Color Scheme
The absolute best way to setup and install a color scheme is to use the Kiosk Admin Tool. It will allow to bring up the theme dialog. Whether you create your own color scheme or use an existing one use of the Kiosk Admin Tool is safest and most efficient way to import or select the color default and theme. Same with Style and Windows Decorations. Once you have setup the decorations, style and color themes click on save and exit .Kiosk Admin Tool. Test and see all your work come together in the test account.
Step Fourteen: Set the Default Ksplash Theme
You will have to create the file that sets the default KSplash theme. To do so use the following command:
kdesu kate /etc/kde-profile/default/share/config/ksplashrc
Simply put in the following two lines:
[KSplash]
Theme=name of ksplash theme
Save the file.
Step Fifteen: Set the KDM Theme
Unfortunately the kdmrc file on this setup is bad. Since its easier to replace it than to fix it I am including a copy of my kdmrc file in this package. Simply take my kdmrc and as root copy it to /etc/kde3/kdm and over write the current kdmrc file. Then edit the file by hand:
kdesu kate /etc/kde3/kdm/kdmrc
Look for the line Theme= and place the path to and the name of the KDM theme there. You will be glad to know you will be able to use the KDM theme manager after that. Because the KDM theme setting is global that's all you need to do.
Step Sixteen: Login Manager Settings
Like KDM this is a global setting so its a quick and simple one. In Kcontrol under 'System Administration' select 'Login Manager'. Click on 'Administrator Mode' and then enter your password. Click the 'Background' tab and select the background you want displayed. I personally like to choose the same background as the one in my default settings. You can choose whatever you want of course.
Step Seventeen: Set Default Sounds
You will have to create the file that sets the default sounds. Use the following command to do so:
kdesu kate /etc/kde-profile/default/share/config/knotify.eventsrc
I suggest you cut and paste the following into it:
Now let's look at this one a bit. It took me awhile to figure this out. Unlike other configuration settings this is not a simple if else function, where if the user has settings use them else use default. In other words this works very differently from the other configurations and we need to know what is happenning.
Let's look at the knotify.eventsrc file in my home directory here:
[Textcompletion: no match]
commandline[$e]=
logfile[$e]=
presentation=1
soundfile[$e]=
Carefully look at the user file then look at the default file. You will notice that the lines in the default file fill in the missing lines from the user's file. For example The KDE startup sound is defined in our default file but the lines in the default file do not exist in the users file.
This is a typical entry for a event sound in the users file:
[warning] << Name of Event
commandline[$e]=
logfile[$e]=
presentation=2
soundfile[$e]=<
Add to that any attempt to dig up actual documentation on the file enteries utterly failed. The only thing I could find out is if you set presentation=0 no sound will play for that event even if defined. So in other words I haven't a clue about the rest of the entries and I have no idea what effect the numbers under presentation= does. Though best guess is its a time delay of some kind. Whatever [$e] means, well your guess is as good as mine on that.
So with all that in mind if you decide to define default sounds then here is what I suggest you do to ensure they work. Use the presentation= number as defined from the file I took from my ~/.kde/share/config/ folder.
In the file /etc/kde-profile/default/share/config/knotify.eventsrc make entries like
[event]
presentation=number as defined in the list
soundfile=path/name to file
Do this for each event you want to have a default sound for.
Step Eighteen: Clean Up For ISO Creation
Once you have tested and are satisfied with everything then remove and delete the test user account. Now open a terminal and use the following command:
sudo apt-get clean
Close the terminal.
Step Nineteen: Create the ISO Image
Using Remastersys is pretty straightfoward. In this case we want to make a distributable copy. However, we need to modify the Remastersys config files first.
Select “Modify the remastersys config file to customize options” and click “OK”.
The only two you really need to concern yourself with are Title and Filename. Change those to what you want then return to the main menu.
Select “Make a Distributable copy to share with friends” and click “OK”.
Remastersys will now build your ISO file. That file once made will be located in /home/remastersys/remastersys/filename.iso.
Burn your first CD or DVD and test it out.
Technical Note of Interest: What Is Weird?
When I first started this process I had a major issue with USB thumb drives not being automounted. During the course of building my Demo Distribution for my Proof of Concept I had to use pmount and pumount to use my thumb drives. At some point they magically started working while I made the modifications to the default settings. What triggered the automount to start working I have no idea. I do know it just “magically” started working like its supposed to so I am not overly worried about it. You will probably have the same experience and if anyone can figure out what the heck the trigger is I would like to know more for curiosities sake.
Notes On the Process: What I Learned By Doing This
Knowing what can be done and knowing how to do it are, as always, two completely different things. The exercise I put myself through in doing this was to teach myself not only how, but why wasn't it better documented. The information presented in this How To derived from my poking around more than what I found online. If it hadn't been for 'Boo's' notes many aspects of this How To would never have evolved. I think the main reason that documentation is a bit poor is that those who usually do this aren't really users, but developers. Developers are pretty much poor documenters. They generally make and keep notes for their purposes and though other developers can usually understand them the average user gets very confused, very fast. Fortunately with my first computing experience being in development (No I do not write code anymore and have no real desire to) I was able to at least decipher many of the things I did come across to put this How To in a format that a typical end user can read, understand and implement. It does of course assume that the user, in this case, has a working knowledge in KDE Operations and KDE Administration at a minimum.
KDE is remarkably configurable and is in reality very easy to configure. Knowing how to configure it (especially the defaults) is the trick in this case. Because of programs like Remastersys anyone can create a Live CD/DVD with an installer. However, despite the fact that doing a total customization setup for Gnome was easy, for KDE it was not.
This How To IS NOT complete and there are many more aspects that need to be covered. Such as the defining of default system sounds and other settings. Yet it is a definite step into getting this to be a much easier process for us KDE users and supporters. So while I will continue to poke around and add on to this document, it also my hope that others will become more involved as well, and also add on to it. With KDE4 becoming closer everyday to being usable in a full productivity environment the need to update this document for it becomes apparent.
Why did I choose Kubuntu? Mostly because they annoyed me with some of the things they did with Gutsy, and now Hardy. It was a challenge to find all the little locked in defaults they had and I was more than happy to figure out how to circumvent them. Considering that this How To is also a proof of concept the idea is if I can do it to a distribution that locks you down a bit harder then imagine what can be done in a distribution designed to allow you to do this in the first place.
So to that end I have at least made the start of a user friendly How To. So to everyone all I can say is here is what we have always wanted, the information we need to make a completely customized KDE based distribution. Though not complete (yet) it is a definite beginning and best of all written in a much more user friendly format.
Remastersys is a tool that can be used to do 2 things with an existing Debian, Ubuntu or derivative installation.
It can make a full system backup including personal data to a live cd or dvd that you can use anywhere and install.
It can make a distributable copy you can share with friends. This will not have any of your personal user data in it.
How did it come to be?
It was initially created by my desire to be able to easily backup or create a distributable copy of an Ubuntu or derivative installation. Inspiration for this tool came from the mklivecd script that Mandriva uses and the remasterme script that is in PCLinuxOS. I had originally looked at some way to port these over to Ubuntu but that proved to be way too much work as it wasn't compatible with casper and ubiquity and used too many Mandriva specific things, so I set out to create remastersys from scratch.
After studying casper and ubiquity along with some wikis on the internet, I created the first version of remastersys. The biggest problem had to do with the making of the live cd user. I had initially made a small workaround that created the livecd user during the building of the livecd system but that wasn't always consistent and became a showstopper with Feisty. I took a few months off from working on it to enjoy the summer with my family.
I was about to give up on it until I received a nice message from Chris of Klikit who informed me he had used remastersys to create Klikit. After taking a look at Klikit and seeing how great it was, I decided to push the rest of the way and finish it. I ironed out the last few bugs and remastersys 2.0 was born.
The Debian port came to be from interest in the debian community as they could not get the Ubuntu version to work due to dependencies specific to Ubuntu.
As soon as I finished working on the remastersys-installer which is a very basic text-based installer, I started working on the debian port. There are many shared ideas and tools between debian and ubuntu so it wasn't all that hard but since no installer was present I waited until I finished it in order for remastersys to be a full service tool for Debian. This is the only reason it took so long.
Thanks to all the testers of both versions without whose help I wouldn't have had the confidence to release it to everyone.
At the moment I, Tony Brijeski, am the only developer/coder/scripter or whatever you want to call me, that has created remastersys, remastersys-gui and remastersys-installer and continue to work on it.
Remastersys is almost never stagnant. I don't have any release schedules as I release new versions as I come up with better ways to do things or fixes or workarounds need to be put in place and I'm notified of them through the forum.
This explanation is intended to show how maintainer scripts work, in a more graphical manner than the one explained in the Debian Policy. It's not intended as a replacement, but as a clarification.
For that purpose, this is going to be illustrated with several diagrams (made with dia). In the figures, the maintainer scripts called and their params are showed inside boxes, the possible outcomes ("OK" or "FAILED") lead to different consequences. External actions to the maintainer scripts are showed in italics, while the package ending status is showed in bold.
Installation
Let's start with the most simple example: the installation of a new package, one that wasn't installed first.
Let's explain this figure a little bit: when a package is being installed, first preinst install is called, then postinst configure. If all goes well, then the status of the package is Installed.
But, if something in the preinst install fails, then postrm abort-install is called. If this goes ok, the user will get an error message, and the package will be left in a Not Installed state. But if the postrm abort-install also fails, the package will be left in a nasty state: Half Installed, Reinst required. This means that the package needs to be reinstalled even if you want to remove it.
If something in the postinst configure fails, then the user is shown an error message, and the package is left in Failed-Config state.
The rest of the figures follow the same pattern, the explanations will be less verbose from now on.
Removal
When removing a package that was previously installed, if everything goes well, the package will be left in the Config Files state, this means that it needs to be purged before it is in the Not installed state.
If something goes wrong at the postrm stage, and the postinst abort-remove script is called, then the package might be left in a strange state: it is still Installed, but the files are not there anymore. If any of the processes fails, when the package removal is tried again, it will resume from where it left (i.e. if the prerm worked and the postrm didn't, it'll resume from the postrm).
Purging
If a package that is in state Config Files has to be purged, the cycle is really simple: the conffiles are deleted and then postrm purge is called.
Removing and Purging
If the package is to be removed and purged at the same time, both diagrams combine, forming a diagram in which the package passes to be Not installed if everything goes ok.
Installing from '''Config-Files''' state
If a package was installed and then removed, but not purged, it's left in Config-Files state. If the installation of a new version is attempted at that moment, the order of the scripts will be almost the same as the simple installation ones, but with a slight difference: the scripts receive a second parameter indicating the old version that used to be present.
The other difference is that if postrm abort-install is called, the package is left in the same state that was before the install was attempted (i.e Config-Files).
Upgrading
The next step in complexity (and it's a big step) is doing an install that is actually upgrading an already installed package.
As you can see from the diagram, if all goes well four scripts are called, but when things go wrong, it gets much more complicated, and the package might be left in many different states.
Downgrading
(No diagram for downgrading yet.)
Downgrading is generally unsafe, here's the sequence of calls when every script succeeds:
1.2-4->prerm upgrade 1.2-3
1.2-3->preinst upgrade 1.2-4
Files are unpacked
1.2-4->postrm upgrade 1.2-3
1.2-3->postinst configure 1.2-4
This is the same procedure as upgrading, but swapping versions.
Conflicting packages
The only thing left that is in the Policy and not in the previous diagram is when a package is being replaced by one that conflicts with it. I won't deal with it now and here, but if you are willing to do the tests and the diagrams yourself, you are free to edit this page and include them.
Sources for the diagrams
The diagrams used in this page were made with dia, and are available for download at: http://www.marga.com.ar/~marga/debian/diagrams/, all this documentation is GPL and you can make use of it for whatever you like.
Building package from binary .tar.gz. (via Alien) Do not use for .tar.gz from vendors who supply their own installer. (VMWare for example.) http://www.martin-bock.de/pc/pc-0012.html
The world we've made as a result of the level of thinking we have done thus far creates problems that we cannot solve at the same level at which we created them ------------ Albert Einstein
