https://wiki.archlinux.org/api.php?action=feedcontributions&user=Jocom&feedformat=atomArchWiki - User contributions [en]2024-03-29T12:10:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Lightweight_Applications&diff=152929Talk:Lightweight Applications2011-08-22T13:37:49Z<p>Jocom: </p>
<hr />
<div>What are the criteria for what makes software lightweight or not? If Thunderbird is included I find it strange that Firefox isn't included as well.<br />
--[[User:Trontonic|Trontonic]] 20:26, 31 March 2009 (EDT)<br />
:I wouldn't call anything based on Mozilla "lightweight". And definitely not Firefox, which is an infamous resource hog.&mdash;[[User:J. M.|J. M.]] 23:20, 31 March 2009 (EDT)<br />
::[[User:Whoops|Whoops]] 19:24, 11 May 2009 (EDT) Is there actually a "heavier" email client than thunderbird? Maybe it doesn't add much, if someone already uses firefox - I don't know. And i don't know id there's a reason to keep it in the list. Anyone? <br />
:[[User:Whoops|Whoops]] 19:24, 11 May 2009 (EDT) Yes, I think a definition of lightweight would be nice. It doesn't have to be perfect, it doesn't have to be mathematical, it's just got to be there ;). Maybe just something like: "There's NO comparable program in the official repositories, that's better in at least 3 out of 5: CPU usage, RAM usage, few dependencies, small size, start time" - on a minimal arch system, without preload or anything that's not needed to run & use the program. Nobody has to prove it, nobody has to discuss hardware differences or anything that could influence it, but it's still some sort of guideline. Of course there's got to be a heavy alternative for something to be lightweight. And I do hope someone can make up a better definition/guideline.<br />
<br />
== Iron is bad ==<br />
<br />
I've removed Iron. Chromium is already there and Iron is just a bad fork of it. It does not remove any spy-crap, which you can not turn off in Chromium[http://thoughtyblog.wordpress.com/2009/12/16/why-no-one-should-not-use-the-iron-chromium-fork/]. Furthermore they host their source code on Rapidshare (!!!), so there's really no need to promote that piece of shit.<br />
--[[User:Donald-teh-Duck|Donald-teh-Duck]] 19:18, 13 March 2010 (EST)<br />
<br />
== Mono Applications ==<br />
<br />
Do mono applications count? I have nothing against mono but it is a very big package and mono applications tend to take up a lot of ram. I have removed smuxi for this reason; if you disagree, add it back.<br />
<br />
== Why is Chromium included? ==<br />
<br />
How does it come that Chromium is included as a "lightweight" browser? According to my own finding and about all random tests that are to be found on the internet - Chromium will eat your memory for breakfast. This being one random finding to support my case: http://dotnetperls.com/chrome-memory . I thought we all had understood that the memory leaks of old days are gone now. [[User:Rovanion|Rovanion]] 00:38, 4 August 2010 (EDT)<br />
<br />
== Kazehakaze ==<br />
<br />
Kazehakaze is a buggy browser. There are lots and lots of tiny little bugs that drives you crazy once you start to use it. So I removed it.<br />
<br />
== Mousepad ==<br />
<br />
Since Mousepad has seen no new releases for well over a year now, should it still be included? [[User:Khne522|Khne522]] 08:50, 20 May 2011 (EDT)<br />
<br />
== FTP clients ==<br />
Possibly add FTP clients to the list. curlftp would be an option, as well as fuseftp. <br />
Also should decide on a place of where to put these<br />
:I think you should add them to the bottom of the internet section. -- [[User:Karol|Karol]] 22:04, 26 May 2011 (EDT)<br />
<br />
== Network managers ==<br />
Shouldn't netcfg be on the list here? -- [[User:Jocom|Jocom]] 09:37, 22 August 2011 (EDT)</div>Jocomhttps://wiki.archlinux.org/index.php?title=OfflineIMAP&diff=146305OfflineIMAP2011-06-16T04:30:26Z<p>Jocom: /* Configuring */ Refactored a sentence.</p>
<hr />
<div>[[Category:Web Server (English)]]<br />
<br />
[http://offlineimap.org/ OfflineIMAP] is an utility to sync mail from IMAP servers. It does not work with the POP3 protocol or mbox, and is usually paired with a MUA such as [[Mutt]].<br />
<br />
As of 06/26/2010, the original author of offlineimap [http://article.gmane.org/gmane.mail.imap.offlineimap.general/1759 ceased development]. A new maintainer has since [http://lists.alioth.debian.org/pipermail/offlineimap-project/2010-November/000286.html stepped forward] and as of 12/16/2010 developed seemed to be active.<br />
<br />
==Installing==<br />
Install the {{package Official|offlineimap}} package with [[pacman]]:<br />
# pacman -S offlineimap<br />
<br />
==Configuring==<br />
The example configuration that is distributed with offlineimap contains every setting and is thorougly documented.<br />
<br />
Copy it to {{filename|~/.offlineimaprc}} and edit it:<br />
$ cp /usr/share/offlineimap/offlineimap.conf ~/.offlineimaprc<br />
$ vi ~/.offlineimaprc<br />
<br />
Writing a comment after an option/value on the same line is invalid syntax, hence take care that comments are placed on their own separate line.<br />
<br />
===Quick-start===<br />
Following is a commented version of {{filename|/usr/share/offlineimap.conf.minimal}}. The setup only contains settings that are absolutely necessary.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This should contain a space delimited list of all identifiers of the accounts<br />
# that are to be synced<br />
accounts = main<br />
# If there are two accounts; `main' and `alternative'...<br />
#accounts = main alternative<br />
<br />
[Account main]<br />
# The identifier for the local repository; e.g., the maildir that offlineimap<br />
# will sync with an IMAP server<br />
localrepository = main-local<br />
# The identifier for the remote repository. This is the actual IMAP, which is<br />
# usually foreign to the system<br />
remoterepository = main-remote<br />
<br />
[Repository main-local]<br />
# Currently, offlineimap only supports maildir and IMAP for local repositories<br />
type = Maildir<br />
# Where should the mail be placed?<br />
localfolders = ~/Maildir<br />
<br />
[Repository main-remote]<br />
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP<br />
type = IMAP<br />
remotehost = host.domain.tld<br />
remoteuser = username<br />
</nowiki><br />
}}<br />
<br />
==Usage==<br />
Before running offlineimap, create any parent directories that were allocated to local repositories:<br />
$ mkdir ~/Maildir<br />
<br />
Now, run the program:<br />
$ offlineimap<br />
<br />
Mail accounts will now be synced. If anything goes wrong, take a closer look at the error messages. OfflineIMAP is usually very verbose about problems; partly because the developers didn't bother with taking away tracebacks from the final product.<br />
<br />
==Miscellaneous==<br />
''Various settings and improvements''<br />
<br />
===Running offlineimap in the background===<br />
Most other mail transfer agents assume that the user will be using the tool as a [[daemon]] by making the program sync periodically by default. In offlineimap, there are a few settings that control backgrounded tasks.<br />
<br />
Confusingly, they are spread thin all-over the configuration file:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
# In the general section<br />
[general]<br />
# Controls how many accounts may be synced simultaneously<br />
maxsyncaccounts = 1<br />
<br />
# In the account identifier<br />
[Account main]<br />
# Minutes between syncs<br />
autorefresh = 5<br />
# Number of quick-syncs between autorefreshes. Quick-syncs do not update if the<br />
# only changes were to IMAP flags<br />
quick = 10<br />
<br />
# In the remote repository identifier<br />
[Repository main-remote]<br />
# Instead of closing the connection once a sync is complete, offlineimap will<br />
# send empty data to the server to hold the connection open. A value of 60<br />
# attempts to hold the connection for a minute between syncs (both quick and<br />
# autorefresh)<br />
keepalive = 60<br />
</nowiki><br />
}}<br />
<br />
====cron job====<br />
1. Configure background jobs as shown in [[#Running offlineimap in the background]].<br />
<br />
2. Use a log-friendly user interface:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This will suppress anything but errors<br />
ui = Noninteractive.Quiet<br />
</nowiki><br />
}}<br />
<br />
3. Write a wrapper script for [[daemon]]izing programs, or use the one shown below:<br />
{{file|name=/usr/local/bin/start_daemon|content=<br />
<nowiki><br />
#!/bin/sh<br />
<br />
set -efu<br />
<br />
ionice_class=<br />
ionice_priority=<br />
nice=<br />
<br />
while getopts c:p:n: f; do<br />
case $f in<br />
c) ionice_class=$OPTARG;;<br />
p) ionice_priority=$OPTARG;;<br />
n) nice=$OPTARG;;<br />
*) exit 2;;<br />
esac<br />
done<br />
shift $((OPTIND - 1))<br />
<br />
cmd=$*<br />
io=<br />
<br />
if pgrep -u "$(id -u)" -xf -- "$cmd" >/dev/null 2>&1; then<br />
exit 0<br />
fi<br />
<br />
if type ionice >/dev/null 2>&1; then<br />
[ -n "$ionice_class" ] && { io=1; cmd="-c $ionice_class $cmd"; }<br />
[ -n "$ionice_priority" ] && { io=1; cmd="-n $ionice_priority $cmd"; }<br />
[ -n "$io" ] && cmd="ionice $cmd"<br />
fi<br />
<br />
if type nice >/dev/null 2>&1; then<br />
[ -n "$nice" ] && cmd="nice -n $nice $cmd"<br />
fi<br />
<br />
exec $cmd<br />
</nowiki><br />
}}<br />
<br />
4. Finally, add a crontab entry:<br />
$ crontab -e<br />
The line should specify the interpreter for correct {{codeline|pgrep -xf}} results:<br />
*/5 * * * * exec /usr/local/bin/start_daemon -n19 -c2 -p7 python2 /usr/bin/offlineimap <br />
<br />
If you are using offlineimap-git from AUR, you'll want to change python2 to python<br />
<br />
The wrapper script is needed because offlineimap has the tendency to sporadically crash, even more so when facing connection problems.<br />
<br />
===Automatic mutt mailbox generation===<br />
[[Mutt]] cannot be simply pointed to an IMAP or maildir directory and be expected to guess which subdirectories happen to be the mailboxes, yet offlineimap can generate a muttrc fragment containing the mailboxes that it syncs.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[mbnames]<br />
enabled = yes<br />
filename = ~/.mutt/mailboxes<br />
header = "mailboxes "<br />
peritem = "+%(accountname)s/%(foldername)s"<br />
sep = " "<br />
footer = "\n"<br />
</nowiki><br />
}}<br />
<br />
Then add {{codeline|source ~/.mutt/mailboxes}} to {{filename|~/.mutt/muttrc}}.<br />
<br />
===Gmail configuration===<br />
This remote repository is configured specifically for Gmail support, substituting folder names in uppercase for lowercase, among other small additions. Keep in mind that this configuration does not sync the ''All Mail'' folder, since it is usually unnecessary and skipping it prevents bandwidth costs:<br />
<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[Repository gmail-remote]<br />
type = Gmail<br />
remoteuser = user@gmail.com<br />
remotepass = password<br />
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',<br />
re.sub ('sent_mail', 'sent',<br />
re.sub ('starred', 'flagged',<br />
re.sub (' ', '_', foldername.lower()))))<br />
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'<br />
</nowiki><br />
}}<br />
<br />
Note: if you have Gmail set to another language, the folder names may appear translated too, e.g. "verzonden_berichten" instead of "sent_mail".<br />
<br />
===Not having to enter the password all the time===<br />
http://www.clasohm.com/blog/one-entry?entry_id=90957 gives an example of how to use gnome-keyring to store the password. <br />
: Anyone know whether this is possible with KDE wallets?<br />
<br />
==Troubleshooting==<br />
<br />
===Overriding UI and autorefresh settings===<br />
For the sake of troubleshooting, it is sometimes convenient to launch offlineimap with a more verbose UI, no background syncs and perhaps even a debug level:<br />
$ offlineimap [ -o ] [ -d <debug_type> ] [ -u <ui> ]<br />
;-o<br />
:Disable autorefresh, keepalive, etc.<br />
<br />
;-d <debug_type><br />
:Where ''<debug_type>'' is one of {{codeline|imap}}, {{codeline|maildir}} or {{codeline|thread}}. Debugging imap and maildir are, by far, the most useful.<br />
<br />
;-u <ui><br />
:Where ''<ui>'' is one of {{codeline|CURSES.BLINKENLIGHTS}}, {{codeline|TTY.TTYUI}}, {{codeline|NONINTERACTIVE.BASIC}}, {{codeline|NONINTERACTIVE.QUIET}} or {{codeline|MACHINE.MACHINEUI}}. TTY.TTYUI is sufficient for debugging purposes.<br />
<br />
===Curses interface (Curses.Blinkenlights) locks terminal===<br />
Because of a bug in Python's ncurses package (http://bugs.python.org/issue7567) the Curses interface of OfflineIMAP breaks the terminal on exit.<br />
While it appears to irreparably lock the terminal, in reality it only prevents commands from being displayed.<br />
The bug has been fixed in Python's SVN for all versions 2.6 up to 3.2 but the current package in the repositories (Python 2.6.5) is still buggy.<br />
<br />
In order to solve the issue:<br />
*either append {{codeline|reset}} to OfflineIMAP's launch command:<br />
$ offlineimap; reset<br />
*or change the {{codeline|ui}} field in {{filename|~/.offlineimaprc}} to select a fully functional one:<br />
ui = TTY.TTYUI<br />
*or as quick workaround you can just use the following command to skip the reset() function in Curses.py which causes the problem<br />
# sed -i '125i\ \ \ \ \ \ \ \ return' /usr/lib/python2.6/site-packages/offlineimap/ui/Curses.py<br />
<br />
===netrc authentication===<br />
There are some bugs in the current {{Package Official|offlineimap}} which makes it impossible to read the authentication data from {{Filename|~/.netrc}}. But they are fixed in the GIT package {{Package AUR|offlineimap-git}} (note that is AUR package is flagged as out of date; see the current GitHub external link below).<br />
Using the package you can collect all passwords in {{Filename|~/.netrc}}. And don't forget to set it's access rights:<br />
chmod 600 ~/.netrc<br />
An example netrc file would be<br />
{{file|name=~/.netrc|content=<br />
machine mail.myhost.de<br />
login mr_smith<br />
password secret<br />
}}<br />
<br />
===socket.ssl deprecation warnings===<br />
Depending on the currently installed python version, running offlineimap throws this warning:<br />
DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead.<br />
<br />
This can be particularly annoying when offlineimap's output is being logged or mailed through [[cron]].<br />
<br />
To fix the problem, apply this [http://github.com/jgoerzen/offlineimap/commit/a7810166335bb0e6f5c7dab26adf707c38adf6ff upstream] patch or install {{Package AUR|offlineimap-git}}:<br />
<pre><br />
--- offlineimap/imaplibutil.py.orig 2009-08-12 01:24:23.000000000 -0430<br />
+++ offlineimap/imaplibutil.py 2010-06-07 11:17:37.849038683 -0430<br />
@@ -23,9 +23,11 @@<br />
# Import the symbols we need that aren't exported by default<br />
from imaplib import IMAP4_PORT, IMAP4_SSL_PORT, InternalDate, Mon2num<br />
<br />
-# ssl is new in python 2.6<br />
-if (sys.version_info[0] == 2 and sys.version_info[1] >= 6) or sys.version_info[0] >= 3:<br />
+try:<br />
import ssl<br />
+ ssl_wrap = ssl.wrap_socket<br />
+except ImportError:<br />
+ ssl_wrap = socket.ssl<br />
<br />
class IMAP4_Tunnel(IMAP4):<br />
"""IMAP4 client class over a tunnel<br />
@@ -169,7 +171,7 @@<br />
if last_error != 0:<br />
# FIXME<br />
raise socket.error(last_error)<br />
- self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)<br />
+ self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile)<br />
self.sslobj = sslwrapper(self.sslobj)<br />
<br />
mustquote = re.compile(r"[^\w!#$%&'+,.:;<=>?^`|~-]")<br />
</pre><br />
<br />
The diff is relative to the root buildir and it can be applied by using [[ABS]].<br />
==External links==<br />
* [http://lists.alioth.debian.org/mailman/listinfo/offlineimap-project Official OfflineIMAP mailing list]<br />
* [http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html Gnus, Dovecot, OfflineIMAP, search: a HOWTO]<br />
** This setup worked for me, only difference being I had to add <code>mail_location = maildir:~/Maildir</code> to <code>/etc/dovecot/dovecot.conf</code>. Also, I used the [[OfflineIMAP#Gmail_configuration|Gmail configuration above]]. --[[User:Unhammer|Unhammer]] 09:24, 22 October 2010 (EDT)<br />
* [http://pbrisbin.com/posts/mutt_gmail_offlineimap/ Mutt + Gmail + Offlineimap]<br />
** An outline of brisbin's simple gmail/mutt setup using cron to keep offlineimap syncing.<br />
* [https://github.com/nicolas33/offlineimap Current OfflineIMAP maintainer's fork on GitHub]<br />
** Note that a strict build of this on current Arch will fail due to python references unless they are replaced with python2</div>Jocomhttps://wiki.archlinux.org/index.php?title=OfflineIMAP&diff=146304OfflineIMAP2011-06-16T04:29:18Z<p>Jocom: /* Configuring */ changed 'since' into 'hence'</p>
<hr />
<div>[[Category:Web Server (English)]]<br />
<br />
[http://offlineimap.org/ OfflineIMAP] is an utility to sync mail from IMAP servers. It does not work with the POP3 protocol or mbox, and is usually paired with a MUA such as [[Mutt]].<br />
<br />
As of 06/26/2010, the original author of offlineimap [http://article.gmane.org/gmane.mail.imap.offlineimap.general/1759 ceased development]. A new maintainer has since [http://lists.alioth.debian.org/pipermail/offlineimap-project/2010-November/000286.html stepped forward] and as of 12/16/2010 developed seemed to be active.<br />
<br />
==Installing==<br />
Install the {{package Official|offlineimap}} package with [[pacman]]:<br />
# pacman -S offlineimap<br />
<br />
==Configuring==<br />
The example configuration that is distributed with offlineimap contains every setting and is thorougly documented.<br />
<br />
Copy it to {{filename|~/.offlineimaprc}} and edit it:<br />
$ cp /usr/share/offlineimap/offlineimap.conf ~/.offlineimaprc<br />
$ vi ~/.offlineimaprc<br />
<br />
Take care that comments are placed on their own separate line, hence writing a comment after an option/value on the same line is invalid syntax.<br />
<br />
===Quick-start===<br />
Following is a commented version of {{filename|/usr/share/offlineimap.conf.minimal}}. The setup only contains settings that are absolutely necessary.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This should contain a space delimited list of all identifiers of the accounts<br />
# that are to be synced<br />
accounts = main<br />
# If there are two accounts; `main' and `alternative'...<br />
#accounts = main alternative<br />
<br />
[Account main]<br />
# The identifier for the local repository; e.g., the maildir that offlineimap<br />
# will sync with an IMAP server<br />
localrepository = main-local<br />
# The identifier for the remote repository. This is the actual IMAP, which is<br />
# usually foreign to the system<br />
remoterepository = main-remote<br />
<br />
[Repository main-local]<br />
# Currently, offlineimap only supports maildir and IMAP for local repositories<br />
type = Maildir<br />
# Where should the mail be placed?<br />
localfolders = ~/Maildir<br />
<br />
[Repository main-remote]<br />
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP<br />
type = IMAP<br />
remotehost = host.domain.tld<br />
remoteuser = username<br />
</nowiki><br />
}}<br />
<br />
==Usage==<br />
Before running offlineimap, create any parent directories that were allocated to local repositories:<br />
$ mkdir ~/Maildir<br />
<br />
Now, run the program:<br />
$ offlineimap<br />
<br />
Mail accounts will now be synced. If anything goes wrong, take a closer look at the error messages. OfflineIMAP is usually very verbose about problems; partly because the developers didn't bother with taking away tracebacks from the final product.<br />
<br />
==Miscellaneous==<br />
''Various settings and improvements''<br />
<br />
===Running offlineimap in the background===<br />
Most other mail transfer agents assume that the user will be using the tool as a [[daemon]] by making the program sync periodically by default. In offlineimap, there are a few settings that control backgrounded tasks.<br />
<br />
Confusingly, they are spread thin all-over the configuration file:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
# In the general section<br />
[general]<br />
# Controls how many accounts may be synced simultaneously<br />
maxsyncaccounts = 1<br />
<br />
# In the account identifier<br />
[Account main]<br />
# Minutes between syncs<br />
autorefresh = 5<br />
# Number of quick-syncs between autorefreshes. Quick-syncs do not update if the<br />
# only changes were to IMAP flags<br />
quick = 10<br />
<br />
# In the remote repository identifier<br />
[Repository main-remote]<br />
# Instead of closing the connection once a sync is complete, offlineimap will<br />
# send empty data to the server to hold the connection open. A value of 60<br />
# attempts to hold the connection for a minute between syncs (both quick and<br />
# autorefresh)<br />
keepalive = 60<br />
</nowiki><br />
}}<br />
<br />
====cron job====<br />
1. Configure background jobs as shown in [[#Running offlineimap in the background]].<br />
<br />
2. Use a log-friendly user interface:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This will suppress anything but errors<br />
ui = Noninteractive.Quiet<br />
</nowiki><br />
}}<br />
<br />
3. Write a wrapper script for [[daemon]]izing programs, or use the one shown below:<br />
{{file|name=/usr/local/bin/start_daemon|content=<br />
<nowiki><br />
#!/bin/sh<br />
<br />
set -efu<br />
<br />
ionice_class=<br />
ionice_priority=<br />
nice=<br />
<br />
while getopts c:p:n: f; do<br />
case $f in<br />
c) ionice_class=$OPTARG;;<br />
p) ionice_priority=$OPTARG;;<br />
n) nice=$OPTARG;;<br />
*) exit 2;;<br />
esac<br />
done<br />
shift $((OPTIND - 1))<br />
<br />
cmd=$*<br />
io=<br />
<br />
if pgrep -u "$(id -u)" -xf -- "$cmd" >/dev/null 2>&1; then<br />
exit 0<br />
fi<br />
<br />
if type ionice >/dev/null 2>&1; then<br />
[ -n "$ionice_class" ] && { io=1; cmd="-c $ionice_class $cmd"; }<br />
[ -n "$ionice_priority" ] && { io=1; cmd="-n $ionice_priority $cmd"; }<br />
[ -n "$io" ] && cmd="ionice $cmd"<br />
fi<br />
<br />
if type nice >/dev/null 2>&1; then<br />
[ -n "$nice" ] && cmd="nice -n $nice $cmd"<br />
fi<br />
<br />
exec $cmd<br />
</nowiki><br />
}}<br />
<br />
4. Finally, add a crontab entry:<br />
$ crontab -e<br />
The line should specify the interpreter for correct {{codeline|pgrep -xf}} results:<br />
*/5 * * * * exec /usr/local/bin/start_daemon -n19 -c2 -p7 python2 /usr/bin/offlineimap <br />
<br />
If you are using offlineimap-git from AUR, you'll want to change python2 to python<br />
<br />
The wrapper script is needed because offlineimap has the tendency to sporadically crash, even more so when facing connection problems.<br />
<br />
===Automatic mutt mailbox generation===<br />
[[Mutt]] cannot be simply pointed to an IMAP or maildir directory and be expected to guess which subdirectories happen to be the mailboxes, yet offlineimap can generate a muttrc fragment containing the mailboxes that it syncs.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[mbnames]<br />
enabled = yes<br />
filename = ~/.mutt/mailboxes<br />
header = "mailboxes "<br />
peritem = "+%(accountname)s/%(foldername)s"<br />
sep = " "<br />
footer = "\n"<br />
</nowiki><br />
}}<br />
<br />
Then add {{codeline|source ~/.mutt/mailboxes}} to {{filename|~/.mutt/muttrc}}.<br />
<br />
===Gmail configuration===<br />
This remote repository is configured specifically for Gmail support, substituting folder names in uppercase for lowercase, among other small additions. Keep in mind that this configuration does not sync the ''All Mail'' folder, since it is usually unnecessary and skipping it prevents bandwidth costs:<br />
<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[Repository gmail-remote]<br />
type = Gmail<br />
remoteuser = user@gmail.com<br />
remotepass = password<br />
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',<br />
re.sub ('sent_mail', 'sent',<br />
re.sub ('starred', 'flagged',<br />
re.sub (' ', '_', foldername.lower()))))<br />
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'<br />
</nowiki><br />
}}<br />
<br />
Note: if you have Gmail set to another language, the folder names may appear translated too, e.g. "verzonden_berichten" instead of "sent_mail".<br />
<br />
===Not having to enter the password all the time===<br />
http://www.clasohm.com/blog/one-entry?entry_id=90957 gives an example of how to use gnome-keyring to store the password. <br />
: Anyone know whether this is possible with KDE wallets?<br />
<br />
==Troubleshooting==<br />
<br />
===Overriding UI and autorefresh settings===<br />
For the sake of troubleshooting, it is sometimes convenient to launch offlineimap with a more verbose UI, no background syncs and perhaps even a debug level:<br />
$ offlineimap [ -o ] [ -d <debug_type> ] [ -u <ui> ]<br />
;-o<br />
:Disable autorefresh, keepalive, etc.<br />
<br />
;-d <debug_type><br />
:Where ''<debug_type>'' is one of {{codeline|imap}}, {{codeline|maildir}} or {{codeline|thread}}. Debugging imap and maildir are, by far, the most useful.<br />
<br />
;-u <ui><br />
:Where ''<ui>'' is one of {{codeline|CURSES.BLINKENLIGHTS}}, {{codeline|TTY.TTYUI}}, {{codeline|NONINTERACTIVE.BASIC}}, {{codeline|NONINTERACTIVE.QUIET}} or {{codeline|MACHINE.MACHINEUI}}. TTY.TTYUI is sufficient for debugging purposes.<br />
<br />
===Curses interface (Curses.Blinkenlights) locks terminal===<br />
Because of a bug in Python's ncurses package (http://bugs.python.org/issue7567) the Curses interface of OfflineIMAP breaks the terminal on exit.<br />
While it appears to irreparably lock the terminal, in reality it only prevents commands from being displayed.<br />
The bug has been fixed in Python's SVN for all versions 2.6 up to 3.2 but the current package in the repositories (Python 2.6.5) is still buggy.<br />
<br />
In order to solve the issue:<br />
*either append {{codeline|reset}} to OfflineIMAP's launch command:<br />
$ offlineimap; reset<br />
*or change the {{codeline|ui}} field in {{filename|~/.offlineimaprc}} to select a fully functional one:<br />
ui = TTY.TTYUI<br />
*or as quick workaround you can just use the following command to skip the reset() function in Curses.py which causes the problem<br />
# sed -i '125i\ \ \ \ \ \ \ \ return' /usr/lib/python2.6/site-packages/offlineimap/ui/Curses.py<br />
<br />
===netrc authentication===<br />
There are some bugs in the current {{Package Official|offlineimap}} which makes it impossible to read the authentication data from {{Filename|~/.netrc}}. But they are fixed in the GIT package {{Package AUR|offlineimap-git}} (note that is AUR package is flagged as out of date; see the current GitHub external link below).<br />
Using the package you can collect all passwords in {{Filename|~/.netrc}}. And don't forget to set it's access rights:<br />
chmod 600 ~/.netrc<br />
An example netrc file would be<br />
{{file|name=~/.netrc|content=<br />
machine mail.myhost.de<br />
login mr_smith<br />
password secret<br />
}}<br />
<br />
===socket.ssl deprecation warnings===<br />
Depending on the currently installed python version, running offlineimap throws this warning:<br />
DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead.<br />
<br />
This can be particularly annoying when offlineimap's output is being logged or mailed through [[cron]].<br />
<br />
To fix the problem, apply this [http://github.com/jgoerzen/offlineimap/commit/a7810166335bb0e6f5c7dab26adf707c38adf6ff upstream] patch or install {{Package AUR|offlineimap-git}}:<br />
<pre><br />
--- offlineimap/imaplibutil.py.orig 2009-08-12 01:24:23.000000000 -0430<br />
+++ offlineimap/imaplibutil.py 2010-06-07 11:17:37.849038683 -0430<br />
@@ -23,9 +23,11 @@<br />
# Import the symbols we need that aren't exported by default<br />
from imaplib import IMAP4_PORT, IMAP4_SSL_PORT, InternalDate, Mon2num<br />
<br />
-# ssl is new in python 2.6<br />
-if (sys.version_info[0] == 2 and sys.version_info[1] >= 6) or sys.version_info[0] >= 3:<br />
+try:<br />
import ssl<br />
+ ssl_wrap = ssl.wrap_socket<br />
+except ImportError:<br />
+ ssl_wrap = socket.ssl<br />
<br />
class IMAP4_Tunnel(IMAP4):<br />
"""IMAP4 client class over a tunnel<br />
@@ -169,7 +171,7 @@<br />
if last_error != 0:<br />
# FIXME<br />
raise socket.error(last_error)<br />
- self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)<br />
+ self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile)<br />
self.sslobj = sslwrapper(self.sslobj)<br />
<br />
mustquote = re.compile(r"[^\w!#$%&'+,.:;<=>?^`|~-]")<br />
</pre><br />
<br />
The diff is relative to the root buildir and it can be applied by using [[ABS]].<br />
==External links==<br />
* [http://lists.alioth.debian.org/mailman/listinfo/offlineimap-project Official OfflineIMAP mailing list]<br />
* [http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html Gnus, Dovecot, OfflineIMAP, search: a HOWTO]<br />
** This setup worked for me, only difference being I had to add <code>mail_location = maildir:~/Maildir</code> to <code>/etc/dovecot/dovecot.conf</code>. Also, I used the [[OfflineIMAP#Gmail_configuration|Gmail configuration above]]. --[[User:Unhammer|Unhammer]] 09:24, 22 October 2010 (EDT)<br />
* [http://pbrisbin.com/posts/mutt_gmail_offlineimap/ Mutt + Gmail + Offlineimap]<br />
** An outline of brisbin's simple gmail/mutt setup using cron to keep offlineimap syncing.<br />
* [https://github.com/nicolas33/offlineimap Current OfflineIMAP maintainer's fork on GitHub]<br />
** Note that a strict build of this on current Arch will fail due to python references unless they are replaced with python2</div>Jocomhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=137914Diskless system2011-04-21T15:01:56Z<p>Jocom: /* Boot Configuration */</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Boot process (English)]]<br />
[[Category:Networking (English)]]<br />
==Root over NFS (diskless boot)==<br />
<br />
This HOWTO will explain the step-by-step method for booting an Arch Linux installation over an NFS share. The first half will primarily cover configuration of the server, and the second will cover client side configuration.<br />
<br />
<!-- This text will contain errors, please report any problems you have with error messages on the talk page. --><br />
<br />
For more information on Network File Sharing, see [[Nfs]].<br />
<br />
==Hardware Considerations==<br />
<br />
Server: <br />
Any standard computer should work, but for performance reasons it should have fast disk access and preferably gigabit ethernet.<br />
<br />
Client:<br />
For a completely diskless boot, the client computer must have a network-bootable (PXE) network card. Wireless will not work, with exception of a wireless-to-ethernet external bridge. Many motherboards have a PXE-compatible ethernet card built in, but you will need to enable support in the BIOS.<br />
<br />
If you don't have a PXE-compatible network card, you can set up a semi-diskless client. This involves building a flashdrive or CD-based boot partition with syslinux or grub. The configuration is the same, but skipping the tftp steps. Creating boot-CDs or flashdrives is beyond the scope of this article.<br />
<br />
For more Information see [http://etherboot.org/ Etherboot/gPXE]<br />
<br />
Prebuilt gPXE images are available from [http://rom-o-matic.net/ http://rom-o-matic.net/]<br />
<br />
=Server-Side Setup=<br />
<br />
The server will have to run a tftp daemon to share the kernel/bootsector along with an NFS share to share the root directory. PXE requires the DHCP server to announce the location of the tftp server to any clients that connect. Most routers will not support this, and this article will show how to modify an existing DNSMasq or DHCPD server. See [[NAT'ing_firewall_-_Share_your_broadband_connection]] for setting up a simple router replacement, including DHCP via DNSMasq, a good place to start for this project. If you do have a router that supports PXE, then you will need to tell it to send all tftp requests to the server.<br />
<br />
At this point I will assume you have a server running with DNSMasq or DHCPd providing DHCP services, along with some space for the client's root.<br />
<br />
First, install nfs-utils, syslinux (for the pxelinux bootloader, you can substitute for GRUB, see [http://wiki.linuxmce.org/index.php/GRUB_PXE_network_boot]).<br />
<pre><br />
pacman -S nfs-utils syslinux<br />
</pre><br />
<br />
==Create Client Root Directory==<br />
<br />
First, create a directory that will hold the root filesystem, this can be anywhere. For this example, I will use /disklessroot.<br />
<pre><br />
mkdir /disklessroot<br />
</pre><br />
<br />
Create a directory for new pacman database,proc and dev mountpoints.<br />
<pre><br />
mkdir -p /disklessroot/var/lib/pacman<br />
mkdir /disklessroot/proc<br />
mkdir /disklessroot/dev<br />
mkdir /disklessroot/sys<br />
</pre><br />
<br />
Mount the /proc and /sys filesystems to allow the installation to use the kernel-provided information within the chrooted environment, and then mount-bind the /dev filesystem.<br />
<pre><br />
mount -t proc none /disklessroot/proc<br />
mount -t sysfs none /disklessroot/sys<br />
mount -o bind /dev /disklessroot/dev<br />
</pre><br />
<br />
Now you need to populate that root with an installation of Arch Linux.<br />
<br />
If you are running 64-bit server and your client is 32-bit, you want to change /etc/pacman.d/mirrorlist entry to point 32-bit architecture. Remember to switch it back after populating client's filesystem. Also you want to add "--arch i686" to the following command.<br />
<pre><br />
pacman -Sy --root /disklessroot --dbpath /disklessroot/var/lib/pacman base<br />
</pre><br />
Install mkinitcpio-nfs-utils for ipconfig and nfsmount tools for NFS root support in mkinitcpio<br />
<pre><br />
pacman -Sy --root /disklessroot --dbpath /disklessroot/var/lib/pacman mkinitcpio-nfs-utils<br />
</pre><br />
Edit /disklessroot/etc/mkinitcpio.conf, add 'nfs' to the MODULE section, and add 'net' after udev under HOOKS..<br />
<pre><br />
MODULES="nfs"<br />
HOOKS="base udev net autodetect pata scsi sata filesystems"<br />
</pre><br />
<br />
Now, chroot into /disklessroot and recreate the kernel image.<br />
<pre><br />
chroot /disklessroot<br />
mkinitcpio -p kernel26<br />
exit<br />
umount /disklessroot/dev<br />
umount /disklessroot/proc<br />
umount /disklessroot/sys<br />
</pre><br />
You should be back to the normal root, the exit command should leave the chroot. Check before continuing.<br />
<br />
==PXE/TFTP Setup==<br />
===Using DNSMasq===<br />
Now to setup tftp and PXE.<br />
<br />
Within DNSMasq, there is an easy-to-use tftp server, so this article will use that.<br />
First, edit /etc/dnsmasq.conf and uncomment these lines, changing them to reflect your file paths.<br />
<pre><br />
dhcp-range=192.168.0.1,192.168.0.100,12h #change ip addresses to your network<br />
# Set the boot filename for BOOTP. You will only need <br />
# this is you want to boot machines over the network and you will need<br />
# a TFTP server; either dnsmasq's built in TFTP server or an<br />
# external one. (See below for how to enable the TFTP server.)<br />
dhcp-boot=pxelinux.0 #change this if you are using GRUB.<br />
<br />
# Enable dnsmasq's built-in TFTP server<br />
enable-tftp<br />
<br />
# Set the root directory for files available via FTP.<br />
tftp-root=/disklessroot/boot/<br />
<br />
#Send options to PXELinux. Note that we need to send the options even<br />
#though they don't appear in the parameter request list, so we need<br />
#to use dhcp-option-force here.<br />
#See http://syslinux.zytor.com/pxe.php#special for details.<br />
#Magic number - needed before anything else is recognised<br />
dhcp-option-force=208,f1:00:74:7e<br />
<br />
#Configuration file name<br />
dhcp-option-force=209,pxelinux.cfg/default<br />
<br />
#Path prefix<br />
dhcp-option-force=210,/disklessroot/boot/<br />
</pre><br />
<br />
This has the additional feature of allowing you to update the kernel within the client OS.<br />
<br />
Make sure the firewall on your server does not block UDP port 69 (UDP ports 67-68 and 4011 are also used, but should not need to be opened).<br />
<br />
=== Using DHCP & XINETD===<br />
If you already have XINETD & DHCP running then you can use them to support net booting in place of the DNSMasq method above. The xinetd service will start the TFTP program on demand as needed.<br />
<br />
First, edit /etc/dhcpd.conf to add the following statements (assuming you already have dhcpd working.)<br />
<br />
<pre><br />
#added for PXE net booting<br />
allow booting;<br />
allow bootp;<br />
group {<br />
next-server 10.0.0.1; #change IP address to match your server<br />
# This is the pxe bootloader file<br />
filename "pxelinux.0";<br />
# One host block per client. This network only has one.<br />
host netboot1 {<br />
#change below to match MAC address of client network device<br />
hardware ethernet 08:00:27:d0:9b:97;<br />
#change below to IP address desired for client <br />
fixed-address 10.0.0.10; <br />
}<br />
}<br />
#group<br />
</pre><br />
<br />
Second, create a file /etc/xinetd.d/tftp with the following lines. After the the xinetd service is restarted the tftpd program will start on demand. <br />
<br />
<pre><br />
service tftp<br />
{<br />
per_source = 11<br />
socket_type = dgram<br />
protocol = udp<br />
user = root<br />
server = /usr/sbin/in.tftpd<br />
server_args = -s /disklessroot/boot<br />
wait = yes<br />
cps = 100 2<br />
}<br />
</pre><br />
<br />
Be sure to restart the DHCP & XINETD services to activate the changes. <br />
<br />
==NFS Setup==<br />
Edit /etc/exports, add this line.<br />
<pre><br />
/disklessroot *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
</pre><br />
If security is an issue, you can replace * with an IP address or IP range to restrict connections. This is semi-redundant with the /etc/hosts.allow configuration below.<br />
<br />
Edit /etc/hosts.allow<br />
<pre><br />
nfsd: 10.0.0.<br />
rpcbind: 10.0.0.<br />
mountd: 10.0.0.<br />
</pre><br />
This partial IP will match everything in the 10.0.0.x range, you can specify a single address, IP range, or simply "ALL" (Insecure!).<br />
<br />
Add "rpcbind nfs-common nfs-server" to the server's /etc/rc.conf under DAEMONS, in that specific order. (Assuming dnsmasq was already installed and on the daemons list.)<br />
<br />
Refer to [[Nfs]] for any configuration/security issues that are not covered here.<br />
<br />
=Client Configuration=<br />
These files are to be edited from the server, as the client is not ready yet.<br />
<br />
==Boot Configuration==<br />
Copy pxelinux.0 to /disklessroot/boot/<br />
<pre><br />
cp /usr/lib/syslinux/pxelinux.0 /disklessroot/boot/<br />
mkdir /disklessroot/boot/pxelinux.cfg<br />
</pre><br />
Create and edit /disklessroot/boot/pxelinux.cfg/default (Replacing IP addresses and file-paths as needed.)<br />
<pre><br />
default linux<br />
<br />
label linux<br />
kernel vmlinuz26<br />
append initrd=kernel26.img rootfstype=nfs root=/dev/nfs nfsroot=10.0.0.1:/disklessroot,v3,rsize=16384,wsize=16384 ip=::::::dhcp<br />
</pre><br />
For more ip option look here [http://wiki.archlinux.org/index.php/Mkinitcpio#Using_net Using net]<br />
<br />
The syntax for the pxelinux bootloader is the same as Syslinux, here[http://syslinux.zytor.com/faq.php] under "CONFIGURATION FILE".<br />
Remember that any filenames will be relative to the tftp server, check the setting in /etc/dnsmasq.conf named "tftp-root=". <br />
This example places tftp-root at /disklessroot/boot/. Thus the kernel should be at /disklessroot/boot/vmlinuz26 on the server, and will show up as /vmlinuz26 for the first stage of client boot. Exactly like a separate /boot partition.<br />
<br />
As there is no entry for / in the clients /etc/fstab file, the client may display the error "mount: can't find / in /etc/fstab or /etc/mtab" on startup. This error can be safely ignored. However, if you want to suppress the error you can add a hack to /etc/fstab. This involves adding the following to /disklessroot/etc/fstab:<br />
<pre><br />
none / none<br />
</pre><br />
<br />
Note:If you want ssh into netbooted machine,add this line to /disklessroot/etc/fstab:<br />
<pre><br />
none /dev/pts devpts gid=5,mode=620 0 0<br />
</pre><br />
Without this,you will get an error that states: "Server refused to allocate pty".<br />
--[[User:Edacval|edacval]] 16:54, 26 October 2008 (EDT)<br />
<br />
=DHCP/Network Daemon Workaround=<br />
This is to prevent the client from trying to reconnect the network and killing itself. Any disconnect of the network and your client will freeze.<br />
<br />
The following workaround involves running the dhcpcd DHCP client on startup with the -s option to use the existing kernel DHCP auto-configured IP address instead of requesting a new one.<br />
Note: This workaround assumes that eth0 is the network interface used for DHCP.<br />
<br />
Edit <code>/etc/conf.d/dhcpcd</code> and append the DHCPCD_ARGS options with <code>-s $(ifconfig eth0 | grep -o '[0-9]*\.[0-9\.]*' | head -n1)</code><br />
<pre><br />
#<br />
# Arguments to be passed to the DHCP client daemon<br />
#<br />
<br />
DHCPCD_ARGS=" -s $(ifconfig eth0 | grep -o '[0-9]*\.[0-9\.]*' | head -n1)"<br />
</pre><br />
<br />
To allow the shutdown process to work properly you must also set the following option in <code>/etc/rc.conf</code> <br />
<pre><br />
NETWORK_PERSIST="yes"<br />
</pre><br />
<br />
<br />
<br />
Another workaround is presented below which configures the DNS server manually.<br />
<br />
=DHCP/Network Daemon Workaround Number 2=<br />
<br />
Edit the client's rc.conf and disable the network daemon (/disklessroot/etc/rc.conf, or just /etc/rc.conf once you boot into the client).<br />
<pre><br />
DAEMONS=(syslog-ng !network ...<br />
</pre><br />
<br />
The main issue with this method is the fact that your resolv.conf will not auto-update (since this bypasses DHCP).<br />
To work around this, edit /etc/resolv.conf and add this line (/disklessroot/etc/resolv.conf on the server).<br />
<pre><br />
nameserver 10.0.0.1 #change this IP for whatever DHCP/DNS server you have, the server's IP usually works if you configured DNS correctly.<br />
</pre><br />
<br />
<br />
=Testing/Debugging the Client=<br />
Now reboot the client computer, making sure the network card is first in the boot-order.<br />
<br />
If all goes right, you should see the network card get an IP address from the server, then connect and boot the kernel. After the initial kernel messages, you should either see Arch Linux boot, or a "killed init" message. <br />
<br />
If init was killed, check your configuration, it usually means it could not mount the NFS folder. Refer to [[Nfs]] for more help. <br />
<br />
If it freezes during a mounting operation, check the client's /etc/fstab or the /boot/pxelinux.cfg/default settings.<br />
<br />
If it freezes duing the "Network" section, either disable it using the previously mentioned workaround, or specify IP settings in /etc/rc.conf. (You can try setting <i>eth0="dhcp"</i>)<br />
<br />
==Performance Notes==<br />
I am currently using a diskless client as my primary internet/development OS due to a hard-drive restriction on my PC. My server is an older machine is running Arch Linux with a software-based raid5 array. My client can read files from the NFS share almost as fast as my server can, but there is a limitation with latency and caching. It slows down during "pacman -Sy" and package installs that involve many small files. Otherwise, it runs fine. It also seems that NFS runs synchronously by default, meaning that all writes have to be committed before continuing, no caching in free memory like it would on a local hard drive. This is actually a good thing, from the data integrity standpoint, as fewer files are lost during a random power outage. I have not tried the "async" NFS option because the nfs man page does not suggest it will work for NFSv3.<br />
<br />
<br />
----<br />
<br />
<br><br><br />
<i>Mostly Complete.<br />
Thank you, Net147, for your excellent edits.<br />
Please edit/update as needed.</i></div>Jocomhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=137912Diskless system2011-04-21T14:41:29Z<p>Jocom: /* Create Client Root Directory */</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Boot process (English)]]<br />
[[Category:Networking (English)]]<br />
==Root over NFS (diskless boot)==<br />
<br />
This HOWTO will explain the step-by-step method for booting an Arch Linux installation over an NFS share. The first half will primarily cover configuration of the server, and the second will cover client side configuration.<br />
<br />
<!-- This text will contain errors, please report any problems you have with error messages on the talk page. --><br />
<br />
For more information on Network File Sharing, see [[Nfs]].<br />
<br />
==Hardware Considerations==<br />
<br />
Server: <br />
Any standard computer should work, but for performance reasons it should have fast disk access and preferably gigabit ethernet.<br />
<br />
Client:<br />
For a completely diskless boot, the client computer must have a network-bootable (PXE) network card. Wireless will not work, with exception of a wireless-to-ethernet external bridge. Many motherboards have a PXE-compatible ethernet card built in, but you will need to enable support in the BIOS.<br />
<br />
If you don't have a PXE-compatible network card, you can set up a semi-diskless client. This involves building a flashdrive or CD-based boot partition with syslinux or grub. The configuration is the same, but skipping the tftp steps. Creating boot-CDs or flashdrives is beyond the scope of this article.<br />
<br />
For more Information see [http://etherboot.org/ Etherboot/gPXE]<br />
<br />
Prebuilt gPXE images are available from [http://rom-o-matic.net/ http://rom-o-matic.net/]<br />
<br />
=Server-Side Setup=<br />
<br />
The server will have to run a tftp daemon to share the kernel/bootsector along with an NFS share to share the root directory. PXE requires the DHCP server to announce the location of the tftp server to any clients that connect. Most routers will not support this, and this article will show how to modify an existing DNSMasq or DHCPD server. See [[NAT'ing_firewall_-_Share_your_broadband_connection]] for setting up a simple router replacement, including DHCP via DNSMasq, a good place to start for this project. If you do have a router that supports PXE, then you will need to tell it to send all tftp requests to the server.<br />
<br />
At this point I will assume you have a server running with DNSMasq or DHCPd providing DHCP services, along with some space for the client's root.<br />
<br />
First, install nfs-utils, syslinux (for the pxelinux bootloader, you can substitute for GRUB, see [http://wiki.linuxmce.org/index.php/GRUB_PXE_network_boot]).<br />
<pre><br />
pacman -S nfs-utils syslinux<br />
</pre><br />
<br />
==Create Client Root Directory==<br />
<br />
First, create a directory that will hold the root filesystem, this can be anywhere. For this example, I will use /disklessroot.<br />
<pre><br />
mkdir /disklessroot<br />
</pre><br />
<br />
Create a directory for new pacman database,proc and dev mountpoints.<br />
<pre><br />
mkdir -p /disklessroot/var/lib/pacman<br />
mkdir /disklessroot/proc<br />
mkdir /disklessroot/dev<br />
mkdir /disklessroot/sys<br />
</pre><br />
<br />
Mount the /proc and /sys filesystems to allow the installation to use the kernel-provided information within the chrooted environment, and then mount-bind the /dev filesystem.<br />
<pre><br />
mount -t proc none /disklessroot/proc<br />
mount -t sysfs none /disklessroot/sys<br />
mount -o bind /dev /disklessroot/dev<br />
</pre><br />
<br />
Now you need to populate that root with an installation of Arch Linux.<br />
<br />
If you are running 64-bit server and your client is 32-bit, you want to change /etc/pacman.d/mirrorlist entry to point 32-bit architecture. Remember to switch it back after populating client's filesystem. Also you want to add "--arch i686" to the following command.<br />
<pre><br />
pacman -Sy --root /disklessroot --dbpath /disklessroot/var/lib/pacman base<br />
</pre><br />
Install mkinitcpio-nfs-utils for ipconfig and nfsmount tools for NFS root support in mkinitcpio<br />
<pre><br />
pacman -Sy --root /disklessroot --dbpath /disklessroot/var/lib/pacman mkinitcpio-nfs-utils<br />
</pre><br />
Edit /disklessroot/etc/mkinitcpio.conf, add 'nfs' to the MODULE section, and add 'net' after udev under HOOKS..<br />
<pre><br />
MODULES="nfs"<br />
HOOKS="base udev net autodetect pata scsi sata filesystems"<br />
</pre><br />
<br />
Now, chroot into /disklessroot and recreate the kernel image.<br />
<pre><br />
chroot /disklessroot<br />
mkinitcpio -p kernel26<br />
exit<br />
umount /disklessroot/dev<br />
umount /disklessroot/proc<br />
umount /disklessroot/sys<br />
</pre><br />
You should be back to the normal root, the exit command should leave the chroot. Check before continuing.<br />
<br />
==PXE/TFTP Setup==<br />
===Using DNSMasq===<br />
Now to setup tftp and PXE.<br />
<br />
Within DNSMasq, there is an easy-to-use tftp server, so this article will use that.<br />
First, edit /etc/dnsmasq.conf and uncomment these lines, changing them to reflect your file paths.<br />
<pre><br />
dhcp-range=192.168.0.1,192.168.0.100,12h #change ip addresses to your network<br />
# Set the boot filename for BOOTP. You will only need <br />
# this is you want to boot machines over the network and you will need<br />
# a TFTP server; either dnsmasq's built in TFTP server or an<br />
# external one. (See below for how to enable the TFTP server.)<br />
dhcp-boot=pxelinux.0 #change this if you are using GRUB.<br />
<br />
# Enable dnsmasq's built-in TFTP server<br />
enable-tftp<br />
<br />
# Set the root directory for files available via FTP.<br />
tftp-root=/disklessroot/boot/<br />
<br />
#Send options to PXELinux. Note that we need to send the options even<br />
#though they don't appear in the parameter request list, so we need<br />
#to use dhcp-option-force here.<br />
#See http://syslinux.zytor.com/pxe.php#special for details.<br />
#Magic number - needed before anything else is recognised<br />
dhcp-option-force=208,f1:00:74:7e<br />
<br />
#Configuration file name<br />
dhcp-option-force=209,pxelinux.cfg/default<br />
<br />
#Path prefix<br />
dhcp-option-force=210,/disklessroot/boot/<br />
</pre><br />
<br />
This has the additional feature of allowing you to update the kernel within the client OS.<br />
<br />
Make sure the firewall on your server does not block UDP port 69 (UDP ports 67-68 and 4011 are also used, but should not need to be opened).<br />
<br />
=== Using DHCP & XINETD===<br />
If you already have XINETD & DHCP running then you can use them to support net booting in place of the DNSMasq method above. The xinetd service will start the TFTP program on demand as needed.<br />
<br />
First, edit /etc/dhcpd.conf to add the following statements (assuming you already have dhcpd working.)<br />
<br />
<pre><br />
#added for PXE net booting<br />
allow booting;<br />
allow bootp;<br />
group {<br />
next-server 10.0.0.1; #change IP address to match your server<br />
# This is the pxe bootloader file<br />
filename "pxelinux.0";<br />
# One host block per client. This network only has one.<br />
host netboot1 {<br />
#change below to match MAC address of client network device<br />
hardware ethernet 08:00:27:d0:9b:97;<br />
#change below to IP address desired for client <br />
fixed-address 10.0.0.10; <br />
}<br />
}<br />
#group<br />
</pre><br />
<br />
Second, create a file /etc/xinetd.d/tftp with the following lines. After the the xinetd service is restarted the tftpd program will start on demand. <br />
<br />
<pre><br />
service tftp<br />
{<br />
per_source = 11<br />
socket_type = dgram<br />
protocol = udp<br />
user = root<br />
server = /usr/sbin/in.tftpd<br />
server_args = -s /disklessroot/boot<br />
wait = yes<br />
cps = 100 2<br />
}<br />
</pre><br />
<br />
Be sure to restart the DHCP & XINETD services to activate the changes. <br />
<br />
==NFS Setup==<br />
Edit /etc/exports, add this line.<br />
<pre><br />
/disklessroot *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
</pre><br />
If security is an issue, you can replace * with an IP address or IP range to restrict connections. This is semi-redundant with the /etc/hosts.allow configuration below.<br />
<br />
Edit /etc/hosts.allow<br />
<pre><br />
nfsd: 10.0.0.<br />
rpcbind: 10.0.0.<br />
mountd: 10.0.0.<br />
</pre><br />
This partial IP will match everything in the 10.0.0.x range, you can specify a single address, IP range, or simply "ALL" (Insecure!).<br />
<br />
Add "rpcbind nfs-common nfs-server" to the server's /etc/rc.conf under DAEMONS, in that specific order. (Assuming dnsmasq was already installed and on the daemons list.)<br />
<br />
Refer to [[Nfs]] for any configuration/security issues that are not covered here.<br />
<br />
=Client Configuration=<br />
These files are to be edited from the server, as the client is not ready yet.<br />
<br />
==Boot Configuration==<br />
Copy pxelinux.0 to /disklessroot/boot/<br />
<pre><br />
cp /usr/lib/syslinux/pxelinux.0 /disklessroot/boot/<br />
mkdir /disklessroot/boot/pxelinux.cfg<br />
</pre><br />
Create and edit /disklessroot/boot/pxelinux.cfg/default (Replacing IP addresses and file-paths as needed.)<br />
<pre><br />
default linux<br />
<br />
label linux<br />
kernel vmlinuz26<br />
append initrd=kernel26.img rootfstype=nfs root=/dev/nfs nfsroot=10.0.0.1:/disklessroot,v3,rsize=16384,wsize=16384 ip=::::::dhcp<br />
</pre><br />
For more ip option look here [http://wiki.archlinux.org/index.php/Mkinitcpio#Using_net Using net]<br />
<br />
The syntax for the pxelinux bootloader is the same as Syslinux, here[http://syslinux.zytor.com/faq.php] under "CONFIGURATION FILE".<br />
Remember that any filenames will be relative to the tftp server, check the setting in /etc/dnsmasq.conf named "tftp-root=". <br />
This example places tftp-root at /disklessroot/boot/. Thus the kernel should be at /disklessroot/boot/vmlinuz26 on the server, and will show up as /vmlinuz26 for the first stage of client boot. Exactly like a separate /boot partition.<br />
<br />
As there is no entry for / in the clients /etc/fstab file, the client may display the error "mount: can't find / in /etc/fstab or /etc/mtab" on startup. This error can be safely ignored. However, if you want to suppress the error you can add a hack to /etc/fstab. This involves adding the following to /disklessroot/etc/fstab:<br />
<pre><br />
none / none<br />
</pre><br />
<br />
Note:If you want ssh into netbooteed machine,add this line to /disklessroot/etc/fstab:<br />
<pre><br />
none /dev/pts devpts gid=5,mode=620 0 0<br />
</pre><br />
Without this,you will get an error that states: "Server refused to allocate pty".<br />
--[[User:Edacval|edacval]] 16:54, 26 October 2008 (EDT)<br />
<br />
=DHCP/Network Daemon Workaround=<br />
This is to prevent the client from trying to reconnect the network and killing itself. Any disconnect of the network and your client will freeze.<br />
<br />
The following workaround involves running the dhcpcd DHCP client on startup with the -s option to use the existing kernel DHCP auto-configured IP address instead of requesting a new one.<br />
Note: This workaround assumes that eth0 is the network interface used for DHCP.<br />
<br />
Edit <code>/etc/conf.d/dhcpcd</code> and append the DHCPCD_ARGS options with <code>-s $(ifconfig eth0 | grep -o '[0-9]*\.[0-9\.]*' | head -n1)</code><br />
<pre><br />
#<br />
# Arguments to be passed to the DHCP client daemon<br />
#<br />
<br />
DHCPCD_ARGS=" -s $(ifconfig eth0 | grep -o '[0-9]*\.[0-9\.]*' | head -n1)"<br />
</pre><br />
<br />
To allow the shutdown process to work properly you must also set the following option in <code>/etc/rc.conf</code> <br />
<pre><br />
NETWORK_PERSIST="yes"<br />
</pre><br />
<br />
<br />
<br />
Another workaround is presented below which configures the DNS server manually.<br />
<br />
=DHCP/Network Daemon Workaround Number 2=<br />
<br />
Edit the client's rc.conf and disable the network daemon (/disklessroot/etc/rc.conf, or just /etc/rc.conf once you boot into the client).<br />
<pre><br />
DAEMONS=(syslog-ng !network ...<br />
</pre><br />
<br />
The main issue with this method is the fact that your resolv.conf will not auto-update (since this bypasses DHCP).<br />
To work around this, edit /etc/resolv.conf and add this line (/disklessroot/etc/resolv.conf on the server).<br />
<pre><br />
nameserver 10.0.0.1 #change this IP for whatever DHCP/DNS server you have, the server's IP usually works if you configured DNS correctly.<br />
</pre><br />
<br />
<br />
=Testing/Debugging the Client=<br />
Now reboot the client computer, making sure the network card is first in the boot-order.<br />
<br />
If all goes right, you should see the network card get an IP address from the server, then connect and boot the kernel. After the initial kernel messages, you should either see Arch Linux boot, or a "killed init" message. <br />
<br />
If init was killed, check your configuration, it usually means it could not mount the NFS folder. Refer to [[Nfs]] for more help. <br />
<br />
If it freezes during a mounting operation, check the client's /etc/fstab or the /boot/pxelinux.cfg/default settings.<br />
<br />
If it freezes duing the "Network" section, either disable it using the previously mentioned workaround, or specify IP settings in /etc/rc.conf. (You can try setting <i>eth0="dhcp"</i>)<br />
<br />
==Performance Notes==<br />
I am currently using a diskless client as my primary internet/development OS due to a hard-drive restriction on my PC. My server is an older machine is running Arch Linux with a software-based raid5 array. My client can read files from the NFS share almost as fast as my server can, but there is a limitation with latency and caching. It slows down during "pacman -Sy" and package installs that involve many small files. Otherwise, it runs fine. It also seems that NFS runs synchronously by default, meaning that all writes have to be committed before continuing, no caching in free memory like it would on a local hard drive. This is actually a good thing, from the data integrity standpoint, as fewer files are lost during a random power outage. I have not tried the "async" NFS option because the nfs man page does not suggest it will work for NFSv3.<br />
<br />
<br />
----<br />
<br />
<br><br><br />
<i>Mostly Complete.<br />
Thank you, Net147, for your excellent edits.<br />
Please edit/update as needed.</i></div>Jocom