https://wiki.archlinux.org/api.php?action=feedcontributions&user=Maxsipos&feedformat=atomArchWiki - User contributions [en]2024-03-29T05:15:48ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=4003User:Maxsipos2005-08-15T03:26:37Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
* [[SB Live! Midi]]<br />
* [[DPMS]]<br />
* [[MAC Address Spoofing]]<br />
* [[Security Task Force]]<br />
* [[Multiple X Keyboard Layouts]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Security_Task_Force&diff=4221Security Task Force2005-08-01T00:02:59Z<p>Maxsipos: /* Infrastructure */</p>
<hr />
<div>[[Category:General]]<br />
[[Category:Security]]<br />
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.<br />
<br />
==Philosophy==<br />
<br />
STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF '''recommendations''' should be optional for all users of Arch Linux.<br />
<br />
==Purpose==<br />
<br />
STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.<br />
<br />
===Mirror update speed===<br />
<br />
STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and <code>pacman -U</code> it.<br />
<br />
===Maintainer's "not-fast-enough" reaction===<br />
<br />
Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages once an important security flaw has been found.<br />
<br />
==Example==<br />
<br />
A big security exploit has been found for <code>package-1.5.8</code>. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of <code>package</code> Arch Linux package. <br />
<br />
Once the maintainer addresses the issue and updates the package to <code>package-1.5.9</code>, the STF member posts on the "Arch-Security" mailing lists something like this:<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See <br />
LINK FROM BUGTRAQ HERE, ...<br />
<br />
Package 1.5.9 fixes these issues and is now available in the repo. If <br />
you are on a slow mirror, you might want to download the package <br />
directly and update it via "pacman -U pkgname". LINK HERE<br />
</pre><br />
<br />
==Implementation==<br />
<br />
===What constitutes an important security update?===<br />
<br />
This is left to STF members. An update to, say, <code>apache</code> would definitely be considered important. On the other hand, member might find a security flaw in <code>gaim</code> not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important. <br />
<br />
It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.<br />
<br />
===Infrastructure===<br />
<br />
STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread or a mailing list should be enough.<br />
<br />
===STF members' duties===<br />
<br />
The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Security_Task_Force&diff=1668Security Task Force2005-08-01T00:01:46Z<p>Maxsipos: /* Maintainer's "not-fast-enough" reaction */</p>
<hr />
<div>[[Category:General]]<br />
[[Category:Security]]<br />
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.<br />
<br />
==Philosophy==<br />
<br />
STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF '''recommendations''' should be optional for all users of Arch Linux.<br />
<br />
==Purpose==<br />
<br />
STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.<br />
<br />
===Mirror update speed===<br />
<br />
STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and <code>pacman -U</code> it.<br />
<br />
===Maintainer's "not-fast-enough" reaction===<br />
<br />
Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages once an important security flaw has been found.<br />
<br />
==Example==<br />
<br />
A big security exploit has been found for <code>package-1.5.8</code>. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of <code>package</code> Arch Linux package. <br />
<br />
Once the maintainer addresses the issue and updates the package to <code>package-1.5.9</code>, the STF member posts on the "Arch-Security" mailing lists something like this:<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See <br />
LINK FROM BUGTRAQ HERE, ...<br />
<br />
Package 1.5.9 fixes these issues and is now available in the repo. If <br />
you are on a slow mirror, you might want to download the package <br />
directly and update it via "pacman -U pkgname". LINK HERE<br />
</pre><br />
<br />
==Implementation==<br />
<br />
===What constitutes an important security update?===<br />
<br />
This is left to STF members. An update to, say, <code>apache</code> would definitely be considered important. On the other hand, member might find a security flaw in <code>gaim</code> not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important. <br />
<br />
It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.<br />
<br />
===Infrastructure===<br />
<br />
STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread should be enough.<br />
<br />
===STF members' duties===<br />
<br />
The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Security_Task_Force&diff=1667Security Task Force2005-08-01T00:01:14Z<p>Maxsipos: /* Maintainer's "not-fast-enough" reaction */</p>
<hr />
<div>[[Category:General]]<br />
[[Category:Security]]<br />
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.<br />
<br />
==Philosophy==<br />
<br />
STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF '''recommendations''' should be optional for all users of Arch Linux.<br />
<br />
==Purpose==<br />
<br />
STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.<br />
<br />
===Mirror update speed===<br />
<br />
STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and <code>pacman -U</code> it.<br />
<br />
===Maintainer's "not-fast-enough" reaction===<br />
<br />
Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages.<br />
<br />
==Example==<br />
<br />
A big security exploit has been found for <code>package-1.5.8</code>. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of <code>package</code> Arch Linux package. <br />
<br />
Once the maintainer addresses the issue and updates the package to <code>package-1.5.9</code>, the STF member posts on the "Arch-Security" mailing lists something like this:<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See <br />
LINK FROM BUGTRAQ HERE, ...<br />
<br />
Package 1.5.9 fixes these issues and is now available in the repo. If <br />
you are on a slow mirror, you might want to download the package <br />
directly and update it via "pacman -U pkgname". LINK HERE<br />
</pre><br />
<br />
==Implementation==<br />
<br />
===What constitutes an important security update?===<br />
<br />
This is left to STF members. An update to, say, <code>apache</code> would definitely be considered important. On the other hand, member might find a security flaw in <code>gaim</code> not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important. <br />
<br />
It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.<br />
<br />
===Infrastructure===<br />
<br />
STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread should be enough.<br />
<br />
===STF members' duties===<br />
<br />
The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Security_Task_Force&diff=1661Security Task Force2005-07-31T15:51:04Z<p>Maxsipos: Removed Alternative 2</p>
<hr />
<div>[[Category:General]]<br />
<br />
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.<br />
<br />
==Philosophy==<br />
<br />
STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF '''recommendations''' should be optional for all users of Arch Linux.<br />
<br />
==Purpose==<br />
<br />
STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.<br />
<br />
===Mirror update speed===<br />
<br />
STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and <code>pacman -U</code> it.<br />
<br />
===Maintainer's "not-fast-enough" reaction===<br />
<br />
Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages. If the package has not been updated by the maintainer in, say, 2 days, an interim package would be created by one or more TU members of STF.<br />
<br />
==Example==<br />
<br />
A big security exploit has been found for <code>package-1.5.8</code>. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of <code>package</code> Arch Linux package. <br />
<br />
Once the maintainer addresses the issue and updates the package to <code>package-1.5.9</code>, the STF member posts on the "Arch-Security" mailing lists something like this:<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See <br />
LINK FROM BUGTRAQ HERE, ...<br />
<br />
Package 1.5.9 fixes these issues and is now available in the repo. If <br />
you are on a slow mirror, you might want to download the package <br />
directly and update it via "pacman -U pkgname". LINK HERE<br />
</pre><br />
<br />
==Implementation==<br />
<br />
===What constitutes an important security update?===<br />
<br />
This is left to STF members. An update to, say, <code>apache</code> would definitely be considered important. On the other hand, member might find a security flaw in <code>gaim</code> not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important. <br />
<br />
It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.<br />
<br />
===Infrastructure===<br />
<br />
STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread should be enough.<br />
<br />
===STF members' duties===<br />
<br />
The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Security_Task_Force&diff=1606Security Task Force2005-07-29T17:33:42Z<p>Maxsipos: Draft</p>
<hr />
<div>[[Category:General]]<br />
<br />
This is a draft of the proposal to create a Security Task Force (STF) centered around Arch Linux. Please feel free to edit the draft in order to improve it and discuss at [http://bbs.archlinux.org/viewtopic.php?t=13985]. Once the idea has (hopefully) passed, this page will be edited to carefully explain the duties of STF members.<br />
<br />
==Philosophy==<br />
<br />
STF should help the developers, not add more work to them. Participation in STF should be voluntary and, with the exception of one or more TUs, left to the non-developers. STF should conform to the Arch Philosophy - following the STF '''recommendations''' should be optional for all users of Arch Linux.<br />
<br />
==Purpose==<br />
<br />
STF should embody the efforts of the "security-conscious" part of the Arch users population. Server owners, maintainers of workstations in production environments as well as concerned personal users would gain the benefit of relatively prompt security updates. STF should help alleviate two important problems.<br />
<br />
===Mirror update speed===<br />
<br />
STF important security notices will include a direct link to the updated package on one of the central servers. This allows the users to manually download the updated package and <code>pacman -U</code> it.<br />
<br />
===Maintainer's "not-fast-enough" reaction===<br />
<br />
Arch Linux developers are volunteers with their own personal lives. They might not have time to promptly address updates of their packages. They might have not heard about a recent security update. STF members would suggest the maintainers to update their packages. If the package has not been updated by the maintainer in, say, 2 days, an interim package would be created by one or more TU members of STF.<br />
<br />
==Example==<br />
<br />
A big security exploit has been found for <code>package-1.5.8</code>. The developer of this package has released 1.5.9 that fixes this exploit. An STF member picks up this information from some mailing list he/she is following. Since the member believes this constitutes an important security update (see below), he/she contacts the maintainer of <code>package</code> Arch Linux package. <br />
<br />
===Alternative 1===<br />
<br />
The maintainer addresses the issue day after that and updates the package to <code>package-1.5.9</code>. The STF member posts on the "Arch-Security" mailing lists something like this:<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See <br />
LINK FROM BUGTRAQ HERE, ...<br />
<br />
Package 1.5.9 fixes these issues and is now available in the repo. If <br />
you are on a slow mirror, you might want to download the package <br />
directly and update it via "pacman -U pkgname". LINK HERE<br />
</pre><br />
<br />
===Alternative 2===<br />
<br />
The maintainer hasn't addressed the issue in 2 or more days. The STF member posts a plea to STF TUs (see below) to build an interim package. Once this package has been built, the member posts on "Arch-Security":<br />
<br />
<pre><br />
Package 1.5.8 has a significant buffer overflow bug, etc. etc. See LINK<br />
FROM BUGTRAQ HERE, ...<br />
<br />
A temporary build of 1.5.9 fixes these security issues and is available <br />
HERE.<br />
</pre><br />
<br />
==Implementation==<br />
<br />
===What constitutes an important security update?===<br />
<br />
This is left to STF members. An update to, say, <code>apache</code> would definitely be considered important. On the other hand, member might find a security flaw in <code>gaim</code> not to be of too much importance. How big the security exploit is also affects the reasoning. If it is a relatively popular network program and allows arbitrary code execution then it will probably be deemed important. <br />
<br />
It is worth noting, though, that STF should aim towards having as little security notices as possible. If there is too many STF notices, the users may feel overwhelmed, or maintaing STF would be too much of a burden. Therefore, STF members would be advised to report only truly important security updates in their judgment.<br />
<br />
===Infrastructure===<br />
<br />
STF members would need an "Arch-security" mailing list, hopefully linked from archlinux.org webpage. For inter-STF discussions, a forum thread should be enough.<br />
<br />
===STF members' duties===<br />
<br />
The members would need to read their favourite security-related mailing list and act accordingly. TUs might need to build some interim packages, however, hopefully that should only be a small number change in PKGBUILD.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=1924User:Maxsipos2005-07-29T16:29:59Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
* [[SB Live! Midi]]<br />
* [[DPMS]]<br />
* [[MAC Address Spoofing]]<br />
* [[Security Task Force]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=SB_Live!_Midi&diff=4247SB Live! Midi2005-07-27T03:32:13Z<p>Maxsipos: </p>
<hr />
<div>[[Category:Audio/Video]]<br />
<br />
We are assuming that you are using kernel 2.6 and that ALSA is properly set up. <br />
<br />
''SB Live!'' uses a wavetable synthesizer for its MIDI output. Therefore, in order to get MIDI output you need to load the SoundFont banks into the card. This is done by the <code>asfxload</code> utility from <code>awesfx</code> package.<br />
<br />
Install <code>awesfx</code> package from the [[AUR]]. Copy the SoundFont files from your SB Live driver CD somewhere on your hdd. On the SB Live! Value CD, they are named: <code>2GMGSMT.SF2</code>, <code>4GMGSMT.SF2</code> and <code>8MBGMSFX.SF2</code>. <br />
<br />
Load the bank by executing <code>asfxload ''bankfile''</code>. See <code>man sfxload</code> for more advanced options. Some users have reported that <code>snd_emu10k1_synth</code> needs to be preloaded in order for this to work.<br />
<br />
===Which bank to load?===<br />
<br />
The bank names (at least for SB Live! Value) correspond to their respective sizes (2 Mb, 4 Mb, 8 Mb). The bigger the bank is, the better the quality, although more RAM is also used, since SB Live Value doesn't have its own memory banks.<br />
<br />
===Automating===<br />
<br />
Put <code>asfxload ''fullbankfilepathname''</code> into <code>/etc/rc.local</code>.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=MAC_address_spoofing&diff=1059MAC address spoofing2005-07-26T23:35:44Z<p>Maxsipos: New page</p>
<hr />
<div>It is possible (for whatever reasons) to make your network card broadcast a different MAC address. Suppose your network interface is <code>ethX</code>. Then, to retrieve your MAC address:<br />
$ ifconfig ethX<br />
<br />
The thing you want is the 6 byte number in the hexadecimal form, something like this:<br />
HWaddr 00:1D:98:5A:D1:3A<br />
<br />
Changing the MAC address is easy, shut down the network interface, change the MAC address and restore the interface. This can be done succinctly, as root:<br />
<pre><br />
$ /etc/rc.d/network stop<br />
$ ifconfig ethX hw ether FF:FF:FF:FF:FF:FF<br />
$ /etc/rc.d/network start<br />
</pre><br />
where <code>FF:FF:FF:FF:FF:FF</code> is your new MAC address.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=1276User:Maxsipos2005-07-26T23:33:51Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
* [[SB Live! Midi]]<br />
* [[DPMS]]<br />
* [[MAC Address Spoofing]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=1262Display Power Management Signaling2005-07-26T23:17:18Z<p>Maxsipos: New page</p>
<hr />
<div>[[Category:XServer]]<br />
<br />
'''DPMS''' (Display Power Management Signaling) is a technology that allows power saving behaviour of monitors when the computer is not in use.<br />
<br />
==Setting up DPMS in X==<br />
<br />
Add the following to your <code>/etc/X11/xorg.conf</code> in the <code>Monitor</code> section:<br />
Option "DPMS" "true"<br />
<br />
Add the following to the <code>ServerLayout</code> section, change the times (in minutes) as necessary:<br />
<pre><br />
Option "StandbyTime" "10"<br />
Option "SuspendTime" "20"<br />
Option "OffTime" "30" <br />
</pre></div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=1014User:Maxsipos2005-07-26T23:13:54Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
* [[SB Live! Midi]]<br />
* [[DPMS]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=CD_Burning&diff=2190CD Burning2005-07-26T23:11:18Z<p>Maxsipos: + mounting an iso image</p>
<hr />
<div>[[Category:CD/DVD]]<br />
<br />
This document outlines the process of granting permissions to access specific CD reading and burning devices, and the commands needed to burn CDs. It does not outline the various GUI tools available.<br />
<br />
===Install cd-burning utilities===<br />
<br />
# pacman -Sy cdrtools<br />
<br />
And if you intend to use <tt>cdrdao</tt> (for writing cue/bin files to cd)<br />
# pacman -S cdrdao<br />
<br />
===Burning an iso-image===<br />
<br />
<br />
To burn an iso-image run (replace ''/dev/hdc'' with the name of your recording device):<br />
# cdrecord -v dev=/dev/hdc isoimage.iso<br />
<br />
===Burning a bin/cue===<br />
<br />
To burn a bin/cue image run (replace ''/dev/hdc'' with the name of your recording device):<br />
# cdrdao write --device /dev/hdc image.cue<br />
<br />
===Making an iso-image from an existing cd===<br />
To copy an existing cd just type (replace ''/dev/hdc'' with the name of your recording device):<br />
# dd if<code>/dev/hdc of</code>/home/user/isoimage.iso<br />
<br />
Or use readcd program, also in the cdrtools package<br />
# readcd -v dev=/dev/hdc -f isoimage.iso<br />
<br />
If the original cd was bootable it will be a bootable image.<br />
<br />
===Making an iso-image from existing files on harddisk===<br />
<br />
To make an iso-image just copy the needed files to one folder, then do a<br />
# mkisofs -V volume_name -J -r -o isoimage.iso ~/folder<br />
<br />
===Mounting an iso-image===<br />
<br />
To test if the iso image is proper, you can mount it:<br />
# mount -t iso9660 -o ro,loop=/dev/loop0 cd_image /cdrom<br />
<br />
===Alternative: Setting up K3B===<br />
<br />
This is a lazy man's way of setting up burning privileges.<br />
<br />
* Install k3b with pacman.<br />
<br />
<code>pacman -S k3b</code><br />
<br />
* As root, run <code>k3bsetup</code>,<br />
* Your choice to use a burning group or not.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=SB_Live!_Midi&diff=1023SB Live! Midi2005-07-26T20:03:12Z<p>Maxsipos: paragraph</p>
<hr />
<div>[[Category:Audio/Video]]<br />
<br />
We are assuming that you are using kernel 2.6 and that ALSA is properly set up. <br />
<br />
''SB Live!'' uses a wavetable synthesizer for its MIDI output. Therefore, in order to get MIDI output you need to load the SoundFont banks into the card. This is done by the <code>asfxload</code> utility from <code>awesfx</code> package.<br />
<br />
Install <code>awesfx</code> package from the [[AUR]]. Copy the SoundFont files from your SB Live driver CD somewhere on your hdd. On the SB Live! Value CD, they are named: <code>2GMGSMT.SF2</code>, <code>4GMGSMT.SF2</code> and <code>8MBGMSFX.SF2</code>. <br />
<br />
Load the bank by executing <code>asfxload ''bankfile''</code>. See <code>man sfxload</code> for more advanced options.<br />
<br />
===Which bank to load?===<br />
<br />
The bank names (at least for SB Live! Value) correspond to their respective sizes (2 Mb, 4 Mb, 8 Mb). The bigger the bank is, the better the quality, although more RAM is also used, since SB Live Value doesn't have its own memory banks.<br />
<br />
===Automating===<br />
<br />
Put <code>asfxload ''fullbankfilepathname''</code> into <code>/etc/rc.local</code>.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=USB_MIDI_keyboards&diff=4244USB MIDI keyboards2005-07-26T20:01:04Z<p>Maxsipos: /* Playing */ oops, wrong link</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[Category:Hardware]]<br />
<br />
==USB Midi Keyboards==<br />
<br />
This how-to assumes that you are using a 2.6 kernel and ALSA. Known to work using this how-to is the Evolution MK-631 USB midi keyboard with SB Live! Value card. Execute these instructions as an unprivileged user unless otherwise noted.<br />
<br />
==Preliminary Testing==<br />
<br />
===USB===<br />
<br />
First let us make sure that USB is working properly. When you type <code>lsmod</code> you should see some modules such as <code>ehci, uhci</code> or such. Also, when you type <code>lsusb</code> you should see something like:<br />
<pre><br />
Bus 004 Device 001: ID 0000:0000<br />
Bus 003 Device 001: ID 0000:0000<br />
Bus 002 Device 001: ID 0000:0000<br />
Bus 001 Device 001: ID 0000:0000<br />
</pre><br />
This list might contain some USB devices if you have them plugged in or more or less items, depending on how many USB ports you have.<br />
<br />
===ALSA===<br />
<br />
You should have ALSA set-up properly (<code>alsa-lib</code> and <code>alsa-utils</code> packages). When you type <code>lsmod | grep snd</code> you should see a bunch of various <code>snd</code> drivers. <br />
<br />
Try typing <code>aseqdump</code>. If you get an error stating that "aseqdump cannot find /dev/snd/seq" or similar, you might not have the <code>snd-seq</code> module loaded. To rectify that, type (as root) <code>modprobe snd-seq</code>. You might also want to add (again as root) <code>snd-seq</code> to your <code>/etc/rc.conf</code> file in the <code>modules</code> list. If the module is succesfully loaded, typing <code>aseqdump</code> should show something like:<br />
<pre><br />
Waiting for data at port 128:0. Press Ctrl+C to end.<br />
Source_ Event_________________ Ch _Data__<br />
</pre><br />
Not much will show up there, so press Ctrl+C to quit the program.<br />
<br />
==Plugging the keyboard==<br />
Now plug the keyboard in and turn it on. The keyboard should power up. Output of <code>lsusb</code> should contain:<br />
<pre><br />
Bus 002 Device 002: ID 0a4d:00a0 Evolution Electronics, Ltd<br />
</pre><br />
<br />
Output of <code>lsmod | grep usb</code> should contain the following modules:<br />
<pre><br />
usb_midi 25348 0<br />
snd_usb_audio 70592 0<br />
snd_usb_lib 16640 1 snd_usb_audio<br />
</pre><br />
<br />
Now type <code>aconnect -i</code>. The output should contain:<br />
<pre><br />
client 72: 'MK-361 USB MIDI keyboard' [type=kernel]<br />
0 'MK-361 USB MIDI keyboard MIDI 1'<br />
</pre><br />
The client number is probably going to be different though. Take note of it.<br />
<br />
==Verifying Events==<br />
Type <code>aseqdump -p ##</code> where you should replace <code>##</code> with the client number of your keyboard. You should see:<br />
<pre><br />
72:0 Active Sensing<br />
</pre><br />
popping out all the time. Pressing a key should produce:<br />
<pre><br />
72:0 Note on 0 65 94<br />
72:0 Note on 0 65 0<br />
</pre><br />
Various other events (turning control knobs, changing channels, etc.) should register in the list. This is a handy way of ensuring that your keyboard is running properly.<br />
<br />
==Playing==<br />
Now type <code>aconnect -o</code> to list the devices listed as ALSA midi outputs. It depends a lot on your sound card. On SB Live! Value, you get the following output:<br />
<pre><br />
client 64: 'EMU10K1 MPU-401 (UART)' [type=kernel]<br />
0 'EMU10K1 MPU-401 (UART)'<br />
client 65: 'Emu10k1 WaveTable' [type=kernel]<br />
0 'Emu10k1 Port 0 '<br />
1 'Emu10k1 Port 1 '<br />
2 'Emu10k1 Port 2 '<br />
3 'Emu10k1 Port 3 '<br />
</pre><br />
Here client 65 is the actual MIDI synthesizer. Assuming the soundcard is [[SB Live! Midi|set up]] properly, you should be able to '''route''' the output of the keyboard to the MIDI synthesizer. Assuming ''out'' is the output client number (65 in our example) and ''in'' is the input client number (72 in our example), type <code>aconnect ''out'' ''in''</code>. Now you can play your keyboard via the MIDI output of your sound card.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=SB_Live!_Midi&diff=996SB Live! Midi2005-07-26T20:00:12Z<p>Maxsipos: New page</p>
<hr />
<div>[[Category:Audio/Video]]<br />
<br />
We are assuming that you are using kernel 2.6 and that ALSA is properly set up. <br />
<br />
''SB Live!'' uses a wavetable synthesizer for its MIDI output. Therefore, in order to get MIDI output you need to load the SoundFont banks into the card. This is done by the <code>asfxload</code> utility from <code>awesfx</code> package.<br />
Install <code>awesfx</code> package from the [[AUR]]. Copy the SoundFont files from your SB Live driver CD somewhere on your hdd. On the SB Live! Value CD, they are named: <code>2GMGSMT.SF2</code>, <code>4GMGSMT.SF2</code> and <code>8MBGMSFX.SF2</code>. <br />
<br />
Load the bank by executing <code>asfxload ''bankfile''</code>. See <code>man sfxload</code> for more advanced options.<br />
<br />
===Which bank to load?===<br />
<br />
The bank names (at least for SB Live! Value) correspond to their respective sizes (2 Mb, 4 Mb, 8 Mb). The bigger the bank is, the better the quality, although more RAM is also used, since SB Live Value doesn't have its own memory banks.<br />
<br />
===Automating===<br />
<br />
Put <code>asfxload ''fullbankfilepathname''</code> into <code>/etc/rc.local</code>.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=1013User:Maxsipos2005-07-26T19:43:23Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
* [[SB Live! Midi]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=USB_MIDI_keyboards&diff=994USB MIDI keyboards2005-07-26T19:41:02Z<p>Maxsipos: </p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[Category:Hardware]]<br />
<br />
==USB Midi Keyboards==<br />
<br />
This how-to assumes that you are using a 2.6 kernel and ALSA. Known to work using this how-to is the Evolution MK-631 USB midi keyboard with SB Live! Value card. Execute these instructions as an unprivileged user unless otherwise noted.<br />
<br />
==Preliminary Testing==<br />
<br />
===USB===<br />
<br />
First let us make sure that USB is working properly. When you type <code>lsmod</code> you should see some modules such as <code>ehci, uhci</code> or such. Also, when you type <code>lsusb</code> you should see something like:<br />
<pre><br />
Bus 004 Device 001: ID 0000:0000<br />
Bus 003 Device 001: ID 0000:0000<br />
Bus 002 Device 001: ID 0000:0000<br />
Bus 001 Device 001: ID 0000:0000<br />
</pre><br />
This list might contain some USB devices if you have them plugged in or more or less items, depending on how many USB ports you have.<br />
<br />
===ALSA===<br />
<br />
You should have ALSA set-up properly (<code>alsa-lib</code> and <code>alsa-utils</code> packages). When you type <code>lsmod | grep snd</code> you should see a bunch of various <code>snd</code> drivers. <br />
<br />
Try typing <code>aseqdump</code>. If you get an error stating that "aseqdump cannot find /dev/snd/seq" or similar, you might not have the <code>snd-seq</code> module loaded. To rectify that, type (as root) <code>modprobe snd-seq</code>. You might also want to add (again as root) <code>snd-seq</code> to your <code>/etc/rc.conf</code> file in the <code>modules</code> list. If the module is succesfully loaded, typing <code>aseqdump</code> should show something like:<br />
<pre><br />
Waiting for data at port 128:0. Press Ctrl+C to end.<br />
Source_ Event_________________ Ch _Data__<br />
</pre><br />
Not much will show up there, so press Ctrl+C to quit the program.<br />
<br />
==Plugging the keyboard==<br />
Now plug the keyboard in and turn it on. The keyboard should power up. Output of <code>lsusb</code> should contain:<br />
<pre><br />
Bus 002 Device 002: ID 0a4d:00a0 Evolution Electronics, Ltd<br />
</pre><br />
<br />
Output of <code>lsmod | grep usb</code> should contain the following modules:<br />
<pre><br />
usb_midi 25348 0<br />
snd_usb_audio 70592 0<br />
snd_usb_lib 16640 1 snd_usb_audio<br />
</pre><br />
<br />
Now type <code>aconnect -i</code>. The output should contain:<br />
<pre><br />
client 72: 'MK-361 USB MIDI keyboard' [type=kernel]<br />
0 'MK-361 USB MIDI keyboard MIDI 1'<br />
</pre><br />
The client number is probably going to be different though. Take note of it.<br />
<br />
==Verifying Events==<br />
Type <code>aseqdump -p ##</code> where you should replace <code>##</code> with the client number of your keyboard. You should see:<br />
<pre><br />
72:0 Active Sensing<br />
</pre><br />
popping out all the time. Pressing a key should produce:<br />
<pre><br />
72:0 Note on 0 65 94<br />
72:0 Note on 0 65 0<br />
</pre><br />
Various other events (turning control knobs, changing channels, etc.) should register in the list. This is a handy way of ensuring that your keyboard is running properly.<br />
<br />
==Playing==<br />
Now type <code>aconnect -o</code> to list the devices listed as ALSA midi outputs. It depends a lot on your sound card. On SB Live! Value, you get the following output:<br />
<pre><br />
client 64: 'EMU10K1 MPU-401 (UART)' [type=kernel]<br />
0 'EMU10K1 MPU-401 (UART)'<br />
client 65: 'Emu10k1 WaveTable' [type=kernel]<br />
0 'Emu10k1 Port 0 '<br />
1 'Emu10k1 Port 1 '<br />
2 'Emu10k1 Port 2 '<br />
3 'Emu10k1 Port 3 '<br />
</pre><br />
Here client 65 is the actual MIDI synthesizer. Assuming the soundcard is [[SB Live! MIDI|set up]] properly, you should be able to '''route''' the output of the keyboard to the MIDI synthesizer. Assuming ''out'' is the output client number (65 in our example) and ''in'' is the input client number (72 in our example), type <code>aconnect ''out'' ''in''</code>. Now you can play your keyboard via the MIDI output of your sound card.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=USB_MIDI_keyboards&diff=988USB MIDI keyboards2005-07-26T18:51:50Z<p>Maxsipos: New page</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[Category:Hardware]]<br />
<br />
==USB Midi Keyboards==<br />
<br />
This how-to assumes that you are using a 2.6 kernel and ALSA. Known to work using this how-to is the Evolution MK-631 USB midi keyboard with SB Live! Value card.<br />
<br />
==Preliminary Testing==<br />
<br />
===USB===<br />
<br />
First let us make sure that USB is working properly. When you type <code>lsmod</code> you should see some modules such as <code>ehci, uhci</code> or such. Also, when you type <code>lsusb</code> you should see something like:<br />
<pre><br />
Bus 004 Device 001: ID 0000:0000<br />
Bus 003 Device 001: ID 0000:0000<br />
Bus 002 Device 001: ID 0000:0000<br />
Bus 001 Device 001: ID 0000:0000<br />
</pre><br />
This list might contain some USB devices if you have them plugged in or more or less items, depending on how many USB ports you have.<br />
<br />
===ALSA===<br />
<br />
You should have ALSA set-up properly (<code>alsa-lib</code> and <code>alsa-utils</code> packages). When you type <code>lsmod | grep snd</code> you should see a bunch of various <code>snd</code> drivers. <br />
<br />
Try typing <code>aseqdump</code>. If you get an error stating that "aseqdump cannot find /dev/snd/seq" or similar, you might not have the <code>snd-seq</code> module loaded. To rectify that, type <code>modprobe snd-seq</code>. You might also want to add <code>snd-seq</code> to your <code>/etc/rc.conf</code> file in the <code>modules</code> list. If the module is succesfully loaded, typing <code>aseqdump</code> should show something like:<br />
<pre><br />
Waiting for data at port 128:0. Press Ctrl+C to end.<br />
Source_ Event_________________ Ch _Data__<br />
</pre><br />
Not much will show up there, so press Ctrl+C to quit the program.<br />
<br />
==Plugging the keyboard==<br />
Now plug the keyboard in and turn it on. The keyboard should power up. Output of <code>lsusb</code> should contain:<br />
<pre><br />
Bus 002 Device 002: ID 0a4d:00a0 Evolution Electronics, Ltd<br />
</pre><br />
<br />
Output of <code>lsmod | grep usb</code> should contain the following modules:<br />
<pre><br />
usb_midi 25348 0<br />
snd_usb_audio 70592 0<br />
snd_usb_lib 16640 1 snd_usb_audio<br />
</pre><br />
<br />
Now type <code>aconnect -i</code>. The output should contain:<br />
<pre><br />
client 72: 'MK-361 USB MIDI keyboard' [type=kernel]<br />
0 'MK-361 USB MIDI keyboard MIDI 1'<br />
</pre><br />
The client number is probably going to be different though. Take note of it.<br />
<br />
==Verifying Events==<br />
Type <code>aseqdump -p ##</code> where you should replace <code>##</code> with the client number of your keyboard. You should see:<br />
<pre><br />
72:0 Active Sensing<br />
</pre><br />
popping out all the time. Pressing a key should produce:<br />
<pre><br />
72:0 Note on 0 65 94<br />
72:0 Note on 0 65 0<br />
</pre><br />
Various other events (turning control knobs, changing channels, etc.) should register in the list. This is a handy way of ensuring that your keyboard is running properly.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=989User:Maxsipos2005-07-26T18:25:20Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
* [[USB Midi Keyboards]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation&diff=4031Kernel Compilation2005-07-24T19:50:49Z<p>Maxsipos: </p>
<hr />
<div></div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=982User:Maxsipos2005-07-24T18:39:24Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]] - Redirect page<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]<br />
* [[Kernel Compilation]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=ABS&diff=4096ABS2005-07-24T18:38:35Z<p>Maxsipos: Redirect page for ABS</p>
<hr />
<div>#REDIRECT [[ABS - The Arch Build System]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=820User:Maxsipos2005-07-24T18:36:16Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
* [[ABS]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]<br />
* [[Kernel Compilation]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation&diff=834Kernel Compilation2005-07-24T18:34:34Z<p>Maxsipos: Changed this article to a general kernel compilation resource</p>
<hr />
<div>[[Category:Kernel]]<br />
<br />
==Kernel Compilation==<br />
<br />
There is multiple ways to compile a custom kernel under Arch.<br />
* [[Kernel Compilation From Source]]<br />
* Via [[ABS]]:<br />
** [[Kernel Compilation With ABS 2.4 | Kernel 2.4]]<br />
** [[Kernel Compilation With ABS (2.6.8 or Earlier) | Kernel 2.6.8 or Earlier]]<br />
** [[Custom Kernel Compilation with ABS (2.6.9 and later) | Kernel 2.6.9 and Later]]<br />
<br />
There is also two other articles.<br />
* [[Kernel Compliation with ABS]]<br />
* [[Kernel PKGBUILD Prototype]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation_without_ABS&diff=2759Kernel Compilation without ABS2005-07-24T18:26:11Z<p>Maxsipos: Copied the article here from Kernel Compilation</p>
<hr />
<div>[[Category:Kernel]]<br />
<br />
==Kernel Compilation From Source==<br />
<br />
You can choose to compile the kernel using <code>/usr/src</code> (this document), or via [[ABS]]: [[Kernel Compilation With ABS]]. A small minority of Arch users prefer the <code>/usr/src</code> way, however using [[ABS]] is helpful for automating certain tasks. The choice is yours, neither way is inherently better than the other.<br />
<br />
The below summary is helpful for building Arch kernels. This normal way of compiling kernels is common to all distros. There is a comprehensive Howto on the subject, for more information: [http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html Kernel-Build-HOWTO]<br />
<br />
* Move the Arch default kernel headers out of the way. This is better than removing them, so you have a backup<br />
# cd /usr/src<br />
# mv linux-2.x.x linux-2.x.x.arch<br />
# mv /lib/modules/linux-2.x.x /lib/modules/linux-2.x.x.arch<br />
# mv /boot/vmlinuz2x vmlinuz-2.x.x.arch<br />
# mv /boot/System.map2x System.map-2.x.x.arch<br />
# mv /boot/kconfig2x /boot/kconfig-2.x.x.arch<br />
<br />
It is a very good idea, to change your grub / lilo config to be able boot this stuff. ''There should be info on how to do this here''<br />
<br />
* Fetch the source from <code>ftp.xx.kernel.org/pub/linux/kernel/</code>, where xx is your country key (f.e. 'us', 'de', 'uk', ... - Check [http://www.kernel.org] for a list of mirrors). If you have no ftp gui, you can use <code>wget</code>. For this example, we will fetch and compile 2.6.6; you should need to change only the version to get a different kernel.<br />
# wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.bz2<br />
<br />
* Move/Copy it to <code>/usr/src</code>.<br />
<br />
* Unpack it<br />
# tar --bzip2 -xvf linux-2.6.6.tar.bz2<br />
<br />
* (Optional) Copy the old .config file, if you want to modify default Arch settings.<br />
# cp /usr/src/linux-2.x.x.arch/.config /usr/src/linux-2.6.6/<br />
<br />
* Change the directory to configure your kernel. Remember to activate devfs stuff if you use it (not if you are a udev user). ''There should be mention of which options these are''<br />
<br />
# rm /usr/src/linux<br />
# ln -s /usr/src/linux-2.66 /usr/src/linux<br />
# cd /usr/src/linux<br />
# make oldconfig (If you've copied the old .config file)<br />
# make menuconfig<br />
<br />
You can also use <code>make xconfig</code> (depends on Qt) or <code>make gconfig</code> (depends on GTK), instead of <code>make menuconfig</code>.<br />
<br />
* Save your config. Its a good idea to make a backup copy, since you will likely be doing this multiple times until you get all the options right.<br />
<br />
* Compile it. Warning: Don't run <code>make all</code> if you use grub and still have lilo installed. It will configure lilo in the end, and you may no longer boot your machine!<br />
<br />
# make -s clean bzImage modules modules_install<br />
<br />
* Copy kernel.<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/boot/bzImage /boot/vmlinuz-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/Kconfig /boot/Kconfig-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/System.map /boot/System.map-2.6.6-revision1<br />
<br />
or, if you run lilo, let the install script copy the files and configure lilo. You are, of course, free to change the name of the <code>kernel</code>, <code>Kconfig</code>, and <code>System.map</code> files. The <code>name-version-revision</code> system is helpful for keeping track which of several kernel compiles you have used. You could also try including a date or time, or stick to a simpler naming system if you wish.<br />
<br />
# cd /usr/src/linux-2.6.5/arch/i386/boot/<br />
# sh ./install.sh<br />
<br />
* Configure [[Grub]] or [[Lilo]], if not already done.<br />
<br />
If you use lilo, remember to type <code>lilo</code> at the prompt to update it.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=819User:Maxsipos2005-07-24T18:25:21Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]<br />
<br />
Rearranged pages:<br />
* [[Kernel Compilation From Source]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=DocBook&diff=4009DocBook2005-07-24T00:19:56Z<p>Maxsipos: Small restructuring</p>
<hr />
<div>[[Category:Desktop]]<br />
[[Category:Devel]]<br />
<br />
We will assume that our docbook document is in <code>File.xml</code><br />
<br />
==Setting up Docbook in Arch==<br />
To set up docbook running on arch:<br />
$ pacman -S docbook-xml docbook-xsl libxslt libxml2<br />
<br />
==Validating XML file==<br />
To validate the XML file use:<br />
$ xmllint --valid --noout File.xml<br />
<br />
This will generate no output if the file is proper XML. <br />
<br />
==Converting into XHTML==<br />
===Single file===<br />
To convert into a XHTML file (single file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl File.xml > Output.html<br />
===Segmented===<br />
To convert into a a segmented XHTML file (each section in its own file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl File.xml<br />
<br />
==Automating==<br />
You can add these to <code>~/.bashrc</code>(or similar shell startup file):<br />
<pre><br />
alias doc2html1="xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl"<br />
alias doc2multihtml="xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl"<br />
alias docvalidate="xmllint --valid --noout"<br />
</pre></div>Maxsiposhttps://wiki.archlinux.org/index.php?title=DocBook&diff=567DocBook2005-07-24T00:15:34Z<p>Maxsipos: Added categories</p>
<hr />
<div>[[Category:Desktop]]<br />
[[Category:Devel]]<br />
<br />
==Setting up Docbook in Arch==<br />
<br />
To set up docbook running on arch:<br />
$ pacman -S docbook-xml docbook-xsl libxslt libxml2<br />
<br />
Assuming our docbook document is in <code>File.xml</code>. To validate the XML file use:<br />
$ xmllint --valid --noout File.xml<br />
<br />
This will generate no output if the file is proper XML. <br />
<br />
Then, to convert into a XHTML file (single file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl File.xml > Output.html<br />
<br />
To convert into a a segmented XHTML file (each section in its own file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl File.xml<br />
<br />
And, of course, you can add these to <code>~/.bashrc</code>(or similar shell startup file):<br />
<pre><br />
alias doc2html1="xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl"<br />
alias doc2multihtml="xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl"<br />
alias docvalidate="xmllint --valid --noout"<br />
</pre></div>Maxsiposhttps://wiki.archlinux.org/index.php?title=DocBook&diff=564DocBook2005-07-24T00:12:51Z<p>Maxsipos: Started docbook page</p>
<hr />
<div>==Setting up Docbook in Arch==<br />
<br />
To set up docbook running on arch:<br />
$ pacman -S docbook-xml docbook-xsl libxslt libxml2<br />
<br />
Assuming our docbook document is in <code>File.xml</code>. To validate the XML file use:<br />
$ xmllint --valid --noout File.xml<br />
<br />
This will generate no output if the file is proper XML. <br />
<br />
Then, to convert into a XHTML file (single file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl File.xml > Output.html<br />
<br />
To convert into a a segmented XHTML file (each section in its own file) use:<br />
xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl File.xml<br />
<br />
And, of course, you can add these to <code>~/.bashrc</code>(or similar shell startup file):<br />
<pre><br />
alias doc2html1="xsltproc /usr/share/xml/docbook/xhtml/docbook.xsl"<br />
alias doc2multihtml="xsltproc /usr/share/xml/docbook/xhtml/chunk.xsl"<br />
alias docvalidate="xmllint --valid --noout"<br />
</pre></div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=817User:Maxsipos2005-07-24T00:09:04Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]<br />
<br />
My pages:<br />
* [[Docbook]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=560User:Maxsipos2005-07-23T23:36:22Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linksys Wireless B]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Boot Problems]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=541User:Maxsipos2005-07-23T23:26:02Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
* [[Kernel Boot Problems]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=527User:Maxsipos2005-07-23T23:25:05Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
* [[Kernel Problems]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Lighttpd_for_SSL_and_non-SSL&diff=966Lighttpd for SSL and non-SSL2005-07-23T21:47:49Z<p>Maxsipos: Import from phpwiki and fix</p>
<hr />
<div>[[Category:Server]]<br />
<br />
==Lighttpd for both ssl and non-ssl==<br />
by CacTus<br />
----<br />
<br />
==What is Lighttpd?==<br />
The lighttpd website gives a good definition.<br />
<br />
<pre><br />
"lighttpd a secure, fast, compliant and very flexible web-server which has been optimized<br />
for high-performance environments. It has a very low memory footprint compared to other<br />
webservers and takes care of cpu-load. Its advanced feature-set (FastCGI, CGI, Auth,<br />
Output-Compression, URL-Rewriting and many more) make lighttpd the perfect<br />
webserver-software for every server that is suffering load problems."<br />
-- http://www.lighttpd.net/<br />
</pre><br />
<br />
==Goals==<br />
The goal of this how to is to setup lighttpd for servicing both ssl and non-ssl connections. php will be setup via a fastcgi prespawn, that will service both ssl and non-ssl connections. The php-fcgi instances will be run as a different user than the lighttpd daemon. eaccelerator will also be setup to increase the efficiency of our php scripts.<br />
<br />
===Required packages:===<br />
*lighttpd (compiled for mysql support)<br />
*php-cgi (compiled for cgi/fcgi support)<br />
*fast-cgi<br />
*eaccelerator<br />
*ssl<br />
<br />
If you have trouble finding a package specific to this How-To, try the resources link at the bottom.<br />
<br />
==Lighttpd Installation==<br />
===Step 1: Install the lighttpd package===<br />
I have lighttpd in my repository, and there is also a version in the AUR, courtesy of klapmuetz. The one in my repository currently contains a few extra things that we will be utilizing for this how to, but they can be obtained individually from my subversion repository if needed. The compiled binaries are the same in the two packages. Just a few different scripts and helper files.<br />
<pre><br />
[[root@computer]]$ pacman -Sy lighttpd<br />
</pre><br />
<br />
===Step 2: Add a user===<br />
We are going to be running lighttpd as a non-root user. So, we first need to create a user for this purpose, and a home directory. We will create a group too.<br />
<pre><br />
[[root@computer]]$ mkdir /home/lighttpd<br />
[[root@computer]]$ groupadd lighttpd<br />
[[root@computer]]$ useradd -g lighttpd -d /home/lighttpd -s /bin/false lighttpd<br />
</pre><br />
<br />
===Step 3: Ensure permissions are properly set.===<br />
<pre><br />
[[root@computer]]$ chown -R lighttpd.lighttpd /home/lighttpd<br />
</pre><br />
<br />
===Step 4: Edit the lighttpd.conf file located at /etc/lighttpd/lighttpd.conf===<br />
*Uncomment modfastcgi and modcompress.<br />
*Uncomment and change server.username to "lighttpd"<br />
*Uncomment and change server.groupname to "lighttpd"<br />
*Uncomment compress.cache-dir and compress.filetype<br />
Save your changes<br />
<br />
===Step 5: Create logfile/edit permissions===<br />
Since we are not running the daemon as root first, the daemon will not be able to create the logfiles on its own. We can give it a little help.<br />
<pre><br />
[[root@computer]]$ touch /var/log/lighttpd/error.log<br />
[[root@computer]]$ touch /var/log/lighttpd/access.log<br />
[[root@computer]]$ chown lighttpd /var/log/lighttpd/*.log<br />
</pre><br />
<br />
===Step 6: Start the daemon.===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd start<br />
</pre><br />
Check /var/log/lighttpd/error.log for any errors. Try bringing up a web page on the server. The default index page should come up. Hooray! You got lighttpd running as a user.<br />
<br />
It is currently only servicing port 80 (non-ssl), so next we add ssl to the mix.<br />
<br />
==Lighttpd SSL==<br />
===Step 1: First things first===<br />
Lighttpd can only service either ssl or non-ssl at one time. No problem. We can easily run two daemons. We need to do a little maintenance work in the lighttpd user directory first.<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd stop<br />
[[root@computer]]$ mkdir -p /home/lighttpd/ssl/html /home/lighttpd/ssl/cache<br />
[[root@computer]]$ mkdir /home/lighttpd/nonssl/cache<br />
[[root@computer]]$ mv /home/lighttpd/html /home/lighttpd/nonssl<br />
[[root@computer]]$ mv /home/lighttpd/cache /home/lighttpd/nonssl<br />
[[root@computer]]$ cp /home/lighttpd/nonssl/html/index.html /home/lighttpd/ssl/html<br />
[[root@computer]]$ chown -R lighttpd.lighttpd /home/lighttpd<br />
</pre><br />
<br />
===Step 2: Copy things===<br />
Now we need to setup a seperate config script, and init script for the ssl version.<br />
<pre><br />
[[root@computer]]$ cp /usr/sbin/lighttpd /usr/sbin/lighttpd-ssl<br />
[[root@computer]]$ cp /etc/rc.d/lighttpd /etc/rc.d/lighttpd-ssl<br />
[[root@computer]]$ cp /etc/lighttpd/lighttpd.conf /etc/lighttpd/lighttpd-ssl.conf<br />
</pre><br />
<br />
===Step 3: Edit /etc/rc.d/lighttpd-ssl===<br />
Change to the following:<br />
<pre><br />
DAEMON_NAME="lighttpd-ssl"<br />
DAEMON_CONF="/etc/lighttpd/lighttpd-ssl.conf"<br />
DAEMON_PATH="/usr/sbin/lighttpd-ssl"<br />
DAEMON_ERRLOG="/var/log/lighttpd/error-ssl.log"<br />
</pre><br />
<br />
===Step 4: Create logfiles for the new daemon===<br />
<pre><br />
[[root@computer]]$ touch /var/log/lighttpd/error-ssl.log<br />
[[root@computer]]$ touch /var/log/lighttpd/access-ssl.log<br />
[[root@computer]]$ chown lighttpd /var/log/lighttpd/*.log<br />
</pre><br />
<br />
===Step 5: Edit /etc/lighttpd/lighttpd-ssl.conf===<br />
Change to the following:<br />
<pre><br />
server.document-root = "/home/lighttpd/ssl/html"<br />
server.errorlog = "/var/log/lighttpd/error-ssl.log"<br />
accesslog.filename = "/var/log/lighttpd/access-ssl.log"<br />
server.pid-file = "/var/run/lighttpd-ssl.pid"<br />
compress.cache-dir = "/home/lighttpd/ssl/cache"<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/home/lighttpd/ssl/server.pem"<br />
</pre><br />
<br />
===Step 6: Edit /etc/lighttpd/lighttpd.conf===<br />
Now that the ssl version is correct, we have to slightly modify the non-ssl version to deal with our new directory structure.<br />
<pre><br />
server.document-root = "/home/lighttpd/nonssl/html"<br />
compress.cache-dir = "/home/lighttpd/nonssl/cache"<br />
</pre><br />
<br />
===Step 7: Create the self signed certificate===<br />
<pre><br />
[[root@computer]]$ cd /home/lighttpd/ssl<br />
[[root@computer]]$ openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes<br />
[[root@computer]]$ chown lighttpd.lighttpd server.pem<br />
[[root@computer]]$ chmod 600 server.pem<br />
</pre><br />
<br />
===Step 8: Start the daemons===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd start<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl start<br />
</pre><br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 9: Test===<br />
Try navigating with a web browser to both the http and https address of your server. Hoory!<br />
You just setup for ssl and nonssl serving using lighttpd.<br />
<br />
==FastCGI and PHP with eAcceleration==<br />
===Step 1: Install fastcgi and php compiled for cgi/fcgi===<br />
<pre><br />
[[root@computer]]$ pacman -S fcgi cactus/php-cgi eaccelerator<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl start<br />
</pre><br />
<br />
===Step 2: Create a php user===<br />
<pre><br />
[[root@computer]]$ mkdir -p /home/phpuser/eaccelerator/cache<br />
[[root@computer]]$ groupadd phpuser<br />
[[root@computer]]$ useradd -g phpuser -d /home/phpuser -s /bin/false phpuser<br />
[[root@computer]]$ chown -R phpuser.phpuser /home/phpuser<br />
</pre><br />
<br />
===Step 3: Add eaccelerator to php.ini and make additional changes===<br />
Note. Make sure you use >> in the following command. If you use a single >, you will overwrite, instead of append. not good.<br />
<pre><br />
[[root@computer]]$ cat /usr/share/eaccelerator/eaccelerator.ini >> /etc/php.ini<br />
</pre><br />
===Step 4: Edit php.ini===<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
<br />
I additionally set safe_mod to On in my setup, but this is not required.<br />
<br />
===Step 5: Setup fcgi-php prespawns===<br />
Now we are going to setup a mechanism for spawning php instances to handle requests.<br />
<pre><br />
[[root@computer]]$ cp /usr/share/lighttpd/spawn-php /etc/rc.d/<br />
[[root@computer]]$ chmod 755 /etc/rc.d/spawn-php<br />
</pre><br />
===Step 6: Modify /etc/rc.d/spawn-php===<br />
You need to edit a few parts of the spawn-php init script.<br />
The following should be set to appropriate values for your setup.<br />
<pre><br />
## bind to tcp-port on localhost<br />
FCGIPORT=\"1066\"<br />
## number of PHP childs to spawn<br />
PHP''FCGI''CHILDREN=12<br />
## number of request server by a single php-process until is will be restarted<br />
PHP''FCGI''MAX_REQUESTS=1000<br />
</pre><br />
<br />
Also, change the following to reflect the php user you created earlier:<br />
USERID=phpuser<br />
GROUPID=phpuser<br />
<br />
===Step 7: Spawn the php instances===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/spawn-php start<br />
</pre><br />
You should get some sort of message saying that is has started child processes.<br />
<br />
To check to see if it indeed has (the spawn script is a bit buggy yet, I haven't worked out the kinks in the wrapper portion).<br />
<pre><br />
[[root@computer]]$ ps afx || grep php<br />
3192 ? Ss 0:00 /usr/bin/php<br />
3193 ? S 0:00 \_ /usr/bin/php<br />
3194 ? S 0:00 \_ /usr/bin/php<br />
3195 ? S 0:00 \_ /usr/bin/php<br />
3196 ? S 0:00 \_ /usr/bin/php<br />
3197 ? S 0:00 \_ /usr/bin/php<br />
3198 ? S 0:00 \_ /usr/bin/php<br />
3199 ? S 0:00 \_ /usr/bin/php<br />
3200 ? S 0:00 \_ /usr/bin/php<br />
3201 ? S 0:00 \_ /usr/bin/php<br />
3202 ? S 0:00 \_ /usr/bin/php<br />
3203 ? S 0:00 \_ /usr/bin/php<br />
3204 ? S 0:00 \_ /usr/bin/php<br />
</pre><br />
<br />
===Step 8: Setup lighttpd and lighttpd-ssl to use the instances===<br />
Edit both /etc/lighttpd/lighttpd.conf and /etc/lighttpd/lighttpd-ssl.conf to contain the following:<br />
<pre><br />
fastcgi.server <code> ( \".php\" </code>><br />
( \"localhost\" =><br />
(<br />
\"host\" => \"127.0.0.1\",<br />
\"port\" => 1066<br />
)<br />
)<br />
)<br />
</pre><br />
<br />
===Step 9: Restart both daemons===<br />
<pre><br />
[[root@computer]]$ /etc/rc.d/lighttpd restart<br />
[[root@computer]]$ /etc/rc.d/lighttpd-ssl restart<br />
</pre><br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 10: Try a php page.===<br />
Create the following php page, name it index.php, and place a copy in both /home/lighttpd/ssl/html and /home/lighttpd/nonssl/html<br />
<pre><br />
<?php<br />
phpinfo();<br />
?><br />
</pre><br />
Try navigating with a web browser to both the http and https address of your server. If you see the phpinfo page, then you are almost done! Hooray!<br />
<br />
===Step 11: Check on eaccelerator caching..===<br />
<pre><br />
[[root@computer]]$ ls -l /home/phpuser/eaccelerator/cache<br />
</pre><br />
If the above command outputs the following:<br />
<pre><br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
</pre><br />
Then you are done! Eaccelerator is happily cachine your php scripts to help speed things up.<br />
Good luck with your setup. :D<br />
<br />
====Resources:====<br />
[[fastcgi and lighttpd]] - klapmuetz's how to on using lighttpd for ruby on rails. It also has good information on lighttpd setup.%%%<br />
[|http://e.solarblue.net/index.php/arch-repo/ Cacuts Repo Information] - Information about my Archlinux repository. Packages used in this howto can be found there.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=525User:Maxsipos2005-07-23T21:25:48Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Lighttpd For Both SSL And Non-SSL]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=449User:Maxsipos2005-07-23T21:06:04Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS (2.6.8 or Earlier)]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=448User:Maxsipos2005-07-23T21:04:29Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS 2.6.8 or Earlier]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=447User:Maxsipos2005-07-23T21:04:20Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
* [[Kernel Compilation With ABS 2.6.8 or Earlier]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=446User:Maxsipos2005-07-23T21:01:19Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]<br />
<br />
Added to:<br />
* [[CD Burning Tips]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation&diff=818Kernel Compilation2005-07-23T20:34:14Z<p>Maxsipos: </p>
<hr />
<div>==Kernel Compilation==<br />
<br />
You can choose to compile the kernel using <code>/usr/src</code> (this document), or via [[ABS]]: [[Kernel Compilation With ABS]]. A small minority of Arch users prefer the <code>/usr/src</code> way, however using [[ABS]] is helpful for automating certain tasks. The choice is yours, neither way is inherently better than the other.<br />
<br />
The below summary is helpful for building Arch kernels. This normal way of compiling kernels is common to all distros. There is a comprehensive Howto on the subject, for more information: [http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html Kernel-Build-HOWTO]<br />
<br />
* Move the Arch default kernel headers out of the way. This is better than removing them, so you have a backup<br />
# cd /usr/src<br />
# mv linux-2.x.x linux-2.x.x.arch<br />
# mv /lib/modules/linux-2.x.x /lib/modules/linux-2.x.x.arch<br />
# mv /boot/vmlinuz2x vmlinuz-2.x.x.arch<br />
# mv /boot/System.map2x System.map-2.x.x.arch<br />
# mv /boot/kconfig2x /boot/kconfig-2.x.x.arch<br />
<br />
It is a very good idea, to change your grub / lilo config to be able boot this stuff. ''There should be info on how to do this here''<br />
<br />
* Fetch the source from <code>ftp.xx.kernel.org/pub/linux/kernel/</code>, where xx is your country key (f.e. 'us', 'de', 'uk', ... - Check [http://www.kernel.org] for a list of mirrors). If you have no ftp gui, you can use <code>wget</code>. For this example, we will fetch and compile 2.6.6; you should need to change only the version to get a different kernel.<br />
# wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.bz2<br />
<br />
* Move/Copy it to <code>/usr/src</code>.<br />
<br />
* Unpack it<br />
# tar --bzip2 -xvf linux-2.6.6.tar.bz2<br />
<br />
* (Optional) Copy the old .config file, if you want to modify default Arch settings.<br />
# cp /usr/src/linux-2.x.x.arch/.config /usr/src/linux-2.6.6/<br />
<br />
* Change the directory to configure your kernel. Remember to activate devfs stuff if you use it (not if you are a udev user). ''There should be mention of which options these are''<br />
<br />
# rm /usr/src/linux<br />
# ln -s /usr/src/linux-2.66 /usr/src/linux<br />
# cd /usr/src/linux<br />
# make oldconfig (If you've copied the old .config file)<br />
# make menuconfig<br />
<br />
You can also use <code>make xconfig</code> (depends on Qt) or <code>make gconfig</code> (depends on GTK), instead of <code>make menuconfig</code>.<br />
<br />
* Save your config. Its a good idea to make a backup copy, since you will likely be doing this multiple times until you get all the options right.<br />
<br />
* Compile it. Warning: Don't run <code>make all</code> if you use grub and still have lilo installed. It will configure lilo in the end, and you may no longer boot your machine!<br />
<br />
# make -s clean bzImage modules modules_install<br />
<br />
* Copy kernel.<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/boot/bzImage /boot/vmlinuz-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/Kconfig /boot/Kconfig-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/System.map /boot/System.map-2.6.6-revision1<br />
<br />
or, if you run lilo, let the install script copy the files and configure lilo. You are, of course, free to change the name of the <code>kernel</code>, <code>Kconfig</code>, and <code>System.map</code> files. The <code>name-version-revision</code> system is helpful for keeping track which of several kernel compiles you have used. You could also try including a date or time, or stick to a simpler naming system if you wish.<br />
<br />
# cd /usr/src/linux-2.6.5/arch/i386/boot/<br />
# sh ./install.sh<br />
<br />
* Configure [[Grub]] or [[Lilo]], if not already done.<br />
<br />
If you use lilo, remember to type <code>lilo</code> at the prompt to update it.<br />
[[Category:Kernel]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=445User:Maxsipos2005-07-23T20:33:19Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]<br />
* [[Kernel Compilation With ABS 2.4]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation&diff=436Kernel Compilation2005-07-23T20:19:19Z<p>Maxsipos: Simple fix</p>
<hr />
<div>==Kernel Compilation==<br />
<br />
You can choose to compile the kernel using <code>/usr/src</code> (this document), or via [[ABS]]: [[Kernel Compilation With ABS]]. A small minority of Arch users prefer the <code>/usr/src</code> way, however using [[ABS]] is helpful for automating certain tasks. The choice is yours, neither way is inherently better than the other.<br />
<br />
The below summary is helpful for building Arch kernels. This normal way of compiling kernels is common to all distros. There is a comprehensive Howto on the subject, for more information: [http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html Kernel-Build-HOWTO]<br />
<br />
* Move the Arch default kernel headers out of the way. This is better than removing them, so you have a backup<br />
# cd /usr/src<br />
# mv linux-2.x.x linux-2.x.x.arch<br />
# mv /lib/modules/linux-2.x.x /lib/modules/linux-2.x.x.arch<br />
# mv /boot/vmlinuz2x vmlinuz-2.x.x.arch<br />
# mv /boot/System.map2x System.map-2.x.x.arch<br />
# mv /boot/kconfig2x /boot/kconfig-2.x.x.arch<br />
<br />
It is a very good idea, to change your grub / lilo config to be able boot this stuff. ''There should be info on how to do this here''<br />
<br />
* Fetch the source from <code>ftp.xx.kernel.org/pub/linux/kernel/</code>, where xx is your country key (f.e. 'us', 'de', 'uk', ... - Check [http://www.kernel.org] for a list of mirrors). If you have no ftp gui, you can use <code>wget</code>. For this example, we will fetch and compile 2.6.6; you should need to change only the version to get a different kernel.<br />
# wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.bz2<br />
<br />
* Move/Copy it to <code>/usr/src</code>.<br />
<br />
* Unpack it<br />
# tar --bzip2 -xvf linux-2.6.6.tar.bz2<br />
<br />
* (Optional) Copy the old .config file, if you want to modify default Arch settings.<br />
# cp /usr/src/linux-2.x.x.arch/.config /usr/src/linux-2.6.6/<br />
<br />
* Change the directory to configure your kernel. Remember to activate devfs stuff if you use it (not if you are a udev user). ''There should be mention of which options these are''<br />
<br />
# rm /usr/src/linux<br />
# ln -s /usr/src/linux-2.66 /usr/src/linux<br />
# cd /usr/src/linux<br />
# make oldconfig (If you've copied the old .config file)<br />
# make menuconfig<br />
<br />
You can also use <code>make xconfig</code> (depends on Qt) or <code>make gconfig</code> (depends on GTK), instead of <code>make menuconfig</code>.<br />
<br />
* Save your config. Its a good idea to make a backup copy, since you will likely be doing this multiple times until you get all the options right.<br />
<br />
* Compile it. Warning: Don't run <code>make all</code> if you use grub and still have lilo installed. It will configure lilo in the end, and you may no longer boot your machine!<br />
<br />
# make -s clean bzImage modules modules_install<br />
<br />
* Copy kernel.<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/boot/bzImage /boot/vmlinuz-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/Kconfig /boot/Kconfig-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/System.map /boot/System.map-2.6.6-revision1<br />
<br />
or, if you run lilo, let the install script copy the files and configure lilo. You are, of course, free to change the name of the <code>kernel</code>, <code>Kconfig</code>, and <code>System.map</code> files. The <code>name-version-revision</code> system is helpful for keeping track which of several kernel compiles you have used. You could also try including a date or time, or stick to a simpler naming system if you wish.<br />
<br />
# cd /usr/src/linux-2.6.5/arch/i386/boot/<br />
# sh ./install.sh<br />
<br />
* Configure [[Grub]] or [[Lilo]], if not already done.<br />
<br />
If you use lilo, remember to type <code>lilo</code> at the prompt to update it.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Kernel_Compilation&diff=427Kernel Compilation2005-07-23T20:16:31Z<p>Maxsipos: Fixing up</p>
<hr />
<div>==Kernel Compilation==<br />
<br />
You can choose to compile the kernel using <code>/usr/src</code> (this document), or via [[ABS]]: [[Kernel Compilation With ABS]]. A small minority of Arch users prefer the <code>/usr/src</code> way, however using [[ABS]] is helpful for automating certain tasks. The choice is yours, neither way is inherently better than the other.<br />
<br />
The below summary is helpful for building Arch kernels. This normal way of compiling kernels is common to all distros. There is a comprehensive Howto on the subject, for more information: [http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html Kernel-Build-HOWTO]<br />
<br />
# Move the Arch default kernel headers out of the way. This is better than removing them, so you have a backup<br />
# cd /usr/src<br />
# mv linux-2.x.x linux-2.x.x.arch<br />
# mv /lib/modules/linux-2.x.x /lib/modules/linux-2.x.x.arch<br />
# mv /boot/vmlinuz2x vmlinuz-2.x.x.arch<br />
# mv /boot/System.map2x System.map-2.x.x.arch<br />
# mv /boot/kconfig2x /boot/kconfig-2.x.x.arch<br />
<br />
It is a very good idea, to change your grub / lilo config to be able boot this stuff. ''There should be info on how to do this here''<br />
<br />
# Fetch the source from <code>ftp.xx.kernel.org/pub/linux/kernel/</code>, where xx is your country key (f.e. 'us', 'de', 'uk', ... - Check [http://www.kernel.org] for a list of mirrors). If you have no ftp gui, you can use <code>wget</code>. For this example, we will fetch and compile 2.6.6; you should need to change only the version to get a different kernel.<br />
# wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.bz2<br />
<br />
# Move/Copy it to <code>/usr/src</code>.<br />
<br />
# Unpack it<br />
# tar --bzip2 -xvf linux-2.6.6.tar.bz2<br />
<br />
# (Optional) Copy the old .config file, if you want to modify default Arch settings.<br />
# cp /usr/src/linux-2.x.x.arch/.config /usr/src/linux-2.6.6/<br />
<br />
# Change the directory to configure your kernel. Remember to activate devfs stuff if you use it (not if you are a udev user). ''There should be mention of which options these are''<br />
<br />
# rm /usr/src/linux<br />
# ln -s /usr/src/linux-2.66 /usr/src/linux<br />
# cd /usr/src/linux<br />
# make oldconfig (If you've copied the old .config file)<br />
# make menuconfig<br />
<br />
You can also use <code>make xconfig</code> (depends on Qt) or <code>make gconfig</code> (depends on GTK), instead of <code>make menuconfig</code>.<br />
<br />
# Save your config. Its a good idea to make a backup copy, since you will likely be doing this multiple times until you get all the options right.<br />
<br />
# Compile it. Warning: Don't run <code>make all</code> if you use grub and still have lilo installed. It will configure lilo in the end, and you may no longer boot your machine!<br />
<br />
# make -s clean bzImage modules modules_install<br />
<br />
# Copy kernel.<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/boot/bzImage /boot/vmlinuz-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/arch/i386/Kconfig /boot/Kconfig-2.6.6-revision1<br />
# cp -v /usr/src/linux-2.6.6/System.map /boot/System.map-2.6.6-revision1<br />
<br />
or, if you run lilo, let the install script copy the files and configure lilo. You are, of course, free to change the name of the <code>kernel</code>, <code>Kconfig</code>, and <code>System.map</code> files. The <code>name-version-revision</code> system is helpful for keeping track which of several kernel compiles you have used. You could also try including a date or time, or stick to a simpler naming system if you wish.<br />
<br />
# cd /usr/src/linux-2.6.5/arch/i386/boot/<br />
# sh ./install.sh<br />
<br />
# Configure [[Grub]] or [[Lilo]], if not already done.<br />
<br />
If you use lilo, remember to type <code>lilo</code> at the prompt to update it.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=435User:Maxsipos2005-07-23T19:56:22Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from phpwiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux And Hardware]]<br />
* [[Linux Conferences]]<br />
* [[Kernel Compilation]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=CD_Burning&diff=1012CD Burning2005-07-23T19:51:24Z<p>Maxsipos: Added content from similar old wiki page</p>
<hr />
<div>[[Category:CD/DVD]]<br />
<br />
This document outlines the process of granting permissions to access specific CD reading and burning devices, and the commands needed to burn CDs. It does not outline the various GUI tools available.<br />
<br />
===Install cd-burning utilities===<br />
<br />
# pacman -Sy cdrtools<br />
<br />
And if you intend to use <tt>cdrdao</tt> (for writing cue/bin files to cd)<br />
# pacman -S cdrdao<br />
<br />
===Burning an iso-image===<br />
<br />
<br />
To burn an iso-image run (replace ''/dev/hdc'' with the name of your recording device):<br />
# cdrecord -v dev=/dev/hdc isoimage.iso<br />
<br />
===Burning a bin/cue===<br />
<br />
To burn a bin/cue image run (replace ''/dev/hdc'' with the name of your recording device):<br />
# cdrdao write --device /dev/hdc image.cue<br />
<br />
===Making an iso-image from an existing cd===<br />
To copy an existing cd just type (replace ''/dev/hdc'' with the name of your recording device):<br />
# dd if<code>/dev/hdc of</code>/home/user/isoimage.iso<br />
<br />
Or use readcd program, also in the cdrtools package<br />
# readcd -v dev=/dev/hdc -f isoimage.iso<br />
<br />
If the original cd was bootable it will be a bootable image.<br />
<br />
===Making an iso-image from existing files on harddisk===<br />
<br />
To make an iso-image just copy the needed files to one folder, then do a<br />
# mkisofs -V volume_name -J -r -o isoimage.iso ~/folder<br />
<br />
===Alternative: Setting up K3B===<br />
<br />
This is a lazy man's way of setting up burning privileges.<br />
<br />
* Install k3b with pacman.<br />
<br />
<code>pacman -S k3b</code><br />
<br />
* As root, run <code>k3bsetup</code>,<br />
* Your choice to use a burning group or not.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=390User:Maxsipos2005-07-23T19:33:04Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from old wiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux Conferences]]<br />
* [[Linux And Hardware]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=Linux_conferences&diff=1360Linux conferences2005-07-23T19:31:01Z<p>Maxsipos: Import and restructuring</p>
<hr />
<div>[[Category:General]]<br />
<br />
The idea behind this page is to make a list of big Linux conferences at which we'd like to have Arch Linux represented. The idea is that we can all contribute to it and coordinate on the dates, details, and who's going.<br />
<br />
Please contribute openly as you like.<br />
<br />
==Conferences==<br />
* Linux Kongress 2005<br /><br />
University of Hamburg, Germany<br /><br />
October 11-14, 2005<br /><br />
[http://www.linux-kongress.org/2005/]<br />
<br />
* Linux World Expo 2006<br /><br />
Boston, MA<br /><br />
April 3-5, 2006<br /><br />
[http://www.linuxworldexpo.com/]<br />
<br />
* LinuxTag 2006<br /><br />
Karlsruhe, Germany<br /><br />
[http://www.linuxtag.org]<br />
<br />
===Notes about conference preparation===<br />
A few notes about conference preparation:<br />
* Make banners. Most likely the information will have changed enough from the last conference to not be able to use the old ones. Banners add a nice look to the drab, boring, grey walls.<br />
* Book hotels '''early'''. If I'm not making myself clear enough, it needs to be as '''early as possible'''. Otherwise you may end up sleeping in a field...<br />
* Try to have at least 2 shifts of people. A booth our size (about 12 square meters) only needed about 4 people at a time. By breaking into two shifts, the booth will be cleaner, have more room in it, and people won't want to all go to lunch at the same time (half went to lunch before they came, the other half go to lunch when they leave).<br />
* Always make sure there's someone in the booth from opening to the end. This means that some people can't party with everyone else the night before. If you rotate the previously mentioned shifts, everyone will have a chance to party with everyone else.<br />
* Have display machines. Nothing is worse than trying to explain how something works to a visitor and not being able to show them.<br />
* Try to have some cool videos running on the display machines. Then they're much less boring when people walk by.<br />
* If you plan on just laying CDs out on the table for anyone to grab, expect to give away a lot of CDs. We ended up having people take about 50 CDs a day, sometimes 2 or 3 at a time. If you plan on giving out CDs like this, look into getting a large bunch pressed: giving away burned CDs marked with a CD pen doesn't exactly look good.<br />
* If you plan on giving away flyers, have them printed before. Also, proof read them to make sure there aren't any silly spelling mistakes. You'll end up giving away more flyers than CDs.<br />
* Don't expect to get a lot of work done while you're in the booth. It's not exactly professional to sit there and force people to approach you because you're deep in some code somewhere.<br />
* Have a donation box. You will get donations.</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=User:Maxsipos&diff=358User:Maxsipos2005-07-23T19:22:20Z<p>Maxsipos: </p>
<hr />
<div>Pages converted from old wiki:<br />
* [[Keymaps]]<br />
* [[Lilo]]<br />
* [[Linux Conferences]]</div>Maxsiposhttps://wiki.archlinux.org/index.php?title=LILO&diff=1375LILO2005-07-23T19:19:00Z<p>Maxsipos: Another change of category</p>
<hr />
<div>[[Category:BootProcess]]<br />
<br />
The '''LInux LOader''', or '''Lilo''' for short, is a still widely used multiboot boot loader for Linux systems. It has been around for several years, but is phased out slowly thanks to the advent of the alternative boot loader [[Grub]], which offers easier configuration and is less prone to leaving a system unbootable.<br />
<br />
LiLo is configured by editing the <code>/etc/lilo.conf</code> file and running <code>lilo</code> afterwards to apply the new configuration. If you chose to use LiLo during the ArchLinux installation process, the configuration file should be setup already just fine.<br />
<br />
More help on setting up LiLo can be found in the [http://www.tldp.org/HOWTO/LILO.html LILO-mini-HOWTO].<br />
<br />
As ArchLinux runs equally well with both loaders, there is no general recommendation to dump LiLo in favor of GRUB. Arch uses GRUB by default, but this is easy to change.</div>Maxsipos