Saving pf state for accounting
Hi guys, My server uses up tons of bandwidth every month and I'd like to start recording what traffic volumes my different services chew up on a monthly basis. My firewall utility of choice is pf and I've recently come across its neat label facility so that I can do a simple pfctl -sl to get the latest readings. That's all fair and well but I lose all that lovely accounting information upon reboot so how do I go about saving this? I've googled quite a bit to look for a solution but have found nothing useful so far, just unanswered posts in the past. From what I can tell so far I'd have to write a custom rc script which redirects pfctl -sl into some sort of logfile which then may be retrieved at a later stage (and added to current counter output). Is there an easier way perhaps? Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ftpd not chroot'ing
Hi guys, I'm trying to set up a really simple, single account write only ftp service. So I put ftpd_enable=YES ftpd_flags=-o -d in my rc.conf and started the ftp server. Now I have a special password enabled user account called camera (none of the other accounts have passwords, all logins are either remote ssh with keys or local terminal access with root) with login shell /bin/sh. So far so good. All I want to do now is now use the chroot facility of ftpd so that when user camera logs in ftpd will chroot the session to its home directory (/home/camera). man ftpd and man ftpchroot tells me to put something like camera yes in /etc/ftpchroot. But once I do that I always get: $ ftp myserver.mydomain.com Connected to myserver.mydomain.com 220 myserver FTP server (Version 6.00LS) ready. Name (mypc:test): camera 331 Password required for camera. Password: 550 Can't change root. Login failed. ftp quit 221 Goodbye. If I disable that line in /etc/ftpchroot by commenting it out I can log in perfectly fine though. Even debug log messages (-d) don't tell me anything more than can't change root :-( The alternative as stated by man ftpd - putting a :ftp-chroot=true: in /etc/login.conf and doing a cap_mkdb /etc/login.conf seems to make no difference as no chroot is in effect (I can still cd .. and get to /home). What am I doing wrong? Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: File system corruption upon reboot with gmirror
Nejc S wrote: Hello, Afaic this only happens on a power loss or otherwise unclean shutdown but I used the reboot command from the shell (in a background (sleep Don't use reboot, use shutdown -r now. I also had the same problem once (had to get physical access to the box to fix it) and it was because of the reboot. Thanks. I guess I'll use shutdown -r now then in future. If it still happens then I'll post again... Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
File system corruption upon reboot with gmirror
Hi guys, I recently updated my FreeBSD 6.3 on our server to the latest patch with freebsd-update and seeing that it involved some kernel patches on 64bit I had to reboot. So I carried out an automated reboot during low-load times but alas, the box never came back up again. After gaining physical access to the console I realised that it choked on the unclean /usr file system and was unable to proceed as the automatic fsck failed, prompting for an emergency shell. An fsck -y followed by a reboot sorted out the issue but it caused a good 1.5h of total downtime which should have been only 4min. So, why was the file system unclean even though I rebooted properly? Afaic this only happens on a power loss or otherwise unclean shutdown but I used the reboot command from the shell (in a background (sleep 21600; reboot) but that shouldn't matter). So surely it would have flushed all the buffers in time? Or is the standard 60 seconds it waits maximum for kernel tasks to finish upon reboot too low and it couldn't finish in time (in which case, how do I change that?)? To give you a bit more background, I run a gmirror(8) RAID 1 over two disks whose health seems intact (zero bad gmirror log entries): $ mount /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Best way of upgrading postgresql in production?
Hi guys,
I've been grappling with this and read all sorts of email threads and
blog posts but I still have no good solution to the following problem: I
want to upgrade a postgresql installation on FreeBSD 6.3 from 8.2 to 8.3
as we'd like to take advantage of its new features and performance
enhancements. Yet none of the ports system offers no clean _and_ quick
way of performing such an upgrade as the Makefiles of the respective
ports choke as soon as they detect an existing older -server or -client.
Yet all I want to do is in a script which fires automatically at 5am via
cron (of course I'll get up to check just in case but I've done this
many times before):
1. Do all backup tasks (build packages for all installed postgresql
8.2 stuff for possible rollback, full database dump, configs etc.)
and take down all processes that write to the db
2. Shut down the database
3. Uninstall all postgresql 8.2 ports (client, server and client libs
we depend on)
4. Install all postgresql 8.3 ports
5. Fire up the new db, restore the complete database dump
6. Restore the configs (pg_hba.conf, postgresql.conf etc.) and
restart the database
7. Start up all db write services again
Ideally that process shouldn't take longer than 5 minutes but step
number 4 is currently a big stumbling block as
* Building from ports will take a while
* I can't find any binary packages for 8.3 (would need i386 for
testing and amd64 for live) anywhere as far as I can see
(ftp.freebsd.org has nothing, nor do the mirrors)
* building binary packages myself is impossible on the same machines
as pkg_create can only do that with installed packages, make
package et. all choke when they realise you already have
82-{client,server} installed and I don't see any other way of
creating a package without installing one
How can I get out of this catch-22 /without /resorting to complicated
jail setups or even worse, manual compilations with different prefixes
and other nasties? There must be a way to get a package somehow...
Gunther
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best way of upgrading postgresql in production?
Bill Moran wrote:
In response to Gunther Mayer [EMAIL PROTECTED]:
I've been grappling with this and read all sorts of email threads and
blog posts but I still have no good solution to the following problem: I
want to upgrade a postgresql installation on FreeBSD 6.3 from 8.2 to 8.3
as we'd like to take advantage of its new features and performance
enhancements. Yet none of the ports system offers no clean _and_ quick
way of performing such an upgrade as the Makefiles of the respective
ports choke as soon as they detect an existing older -server or -client.
Yet all I want to do is in a script which fires automatically at 5am via
cron (of course I'll get up to check just in case but I've done this
many times before):
1. Do all backup tasks (build packages for all installed postgresql
8.2 stuff for possible rollback, full database dump, configs etc.)
and take down all processes that write to the db
2. Shut down the database
3. Uninstall all postgresql 8.2 ports (client, server and client libs
we depend on)
4. Install all postgresql 8.3 ports
5. Fire up the new db, restore the complete database dump
6. Restore the configs (pg_hba.conf, postgresql.conf etc.) and
restart the database
7. Start up all db write services again
Ideally that process shouldn't take longer than 5 minutes but step
number 4 is currently a big stumbling block as
* Building from ports will take a while
* I can't find any binary packages for 8.3 (would need i386 for
testing and amd64 for live) anywhere as far as I can see
(ftp.freebsd.org has nothing, nor do the mirrors)
* building binary packages myself is impossible on the same machines
as pkg_create can only do that with installed packages, make
package et. all choke when they realise you already have
82-{client,server} installed and I don't see any other way of
creating a package without installing one
How can I get out of this catch-22 /without /resorting to complicated
jail setups or even worse, manual compilations with different prefixes
and other nasties? There must be a way to get a package somehow...
Jail setups are not complicated. You could also make the packages on
another system. How about doing a make package on the server that you've
tested your application against 8.3 on? You _have_ done that, right?
That's not an option since my testing box runs i386 while the live one
runs amd64, I guess I should really invest in a testing box with the
same arch...
What makes you think that jail setups are so complicated. I set up new
jails almost every week. I get the impression that you have some reason
for avoiding the obvious solution, and I suspect it revolves around some
incorrect impression that jails are complicated.
Ok, you're probably right, I just haven't worked with jails before and
have just read the wrong articles. I will investigate how I could
install the newer version in a jail and keep both running at the same
time during the upgrade, I'll probably run into more problems along the
way but will post again if I'm stuck.
Thanks,
Gunther
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
The impossible happened, committing suicide
Hi there, I couldn't quite believe it when I saw it. I received an email from cron stating Assertion failed: (0 The impossible happened, committing suicide), function load_plist, file store_txt.c, line 840. Abort trap Obviously a developer's joke, but I'm concerned that there might be a real problem. Would anybody here have any clue as to why this would occur? This happened when executing the following daily (early morning) job on our development server: portsnap cron update /dev/null portsdb -u 2/dev/null [ $(hostname) = mydevserver ] portsearch -u The hostname check we have in there is necessary because while portsearch is handy, it's very resource hungry and thus only tolerable in a testing environment - we share the crontab through svn between our live and dev box. I've now received the same output twice - once yesterday morning and once this morning, chances are I'll get the same tomorrow again... Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Best Java 1.6 JDK for FreeBSD?
Hi guys, We're currently running a busy java web application with diablo-jdk 1.5 and jboss 4.0.5 on FreeBSD 6.2 (yes it's outdated, will upgrade to 6.3 very soon). That combination has proven to be very stable in the past. Now we'd like to start making use of some 1.6 only features in the app and thus were wondering about 1.6 support on java. Now seeing that there's no diablo jdk for 1.6 afaict I have three options: 1. Use linux-sun-jdk 1.6 using the linux compatibility layer 2. Use the native FreeBSD jdk 1.6 (http://www.eyesbeyond.com/freebsddom/java/status.html) but which is officially only beta quality 3. Forget about 1.6 altogether and stick to 1.5 semantics in our code Which one do you think is the most stable option? Well, the way I've put it 3. clearly is the most stable but I'd like an honest consideration of 1. and 2. Does anybody use 1.6 in production on FreeBSD? What have your experiences been? Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
automatic fsck on gmirror failure
Hi there, I have a RAID 1 mirror implemented with gmirror and we recently had some power issues at our data centre which caused fsck to fail mysteriously. The server lost power unexpectedly, then came back up again for a minute, power died again and shortly after the next boot the following appears in my /var/log/messages Feb 2 05:20:19 myserver fsck: /dev/mirror/gm0s1f: INCORRECT BLOCK COUNT I=777684 (8 should be 0) (CORRECTED) Feb 2 05:20:19 myserver fsck: /dev/mirror/gm0s1f: CANNOT READ BLK: 12417184 Feb 2 05:20:19 myserver fsck: /dev/mirror/gm0s1f: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. gm0s1f is my /usr partition. This was followed by countless errors that look like Feb 2 05:20:38 myserver ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=29096879 Feb 2 05:20:43 myserver ad6: TIMEOUT - READ_DMA retrying (0 retries left) LBA=29096879 Feb 2 05:20:48 myserver ad6: FAILURE - READ_DMA timed out LBA=29096879 Feb 2 05:20:48 myserver g_vfs_done():mirror/gm0s1f[READ(offset=6357598208, length=16384)]error = 5 and with it went any sort of remote access to the box. We had to get physical access, fsck -y and reboot for the machine to be put back into service. Now my question is: Why did fsck die on me? I thought in this day and age file system corruptions caused by power failures are repaired automatically upon reboot. Or is it possible that interrupting fsck itself caused the problem when the system went down again after the very brief uptime in between? I am really concerned about this as this caused a lot of unnecessary downtime and I really don't want this to ever happen again. I know, solving the power issues is the real solution but I want my several layers of peace of mind. Oh, I run 6.2 RELEASE. Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Python threading - some ports depend on it, others break with it
Jim Stapleton wrote: I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support. However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things. ... I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken? I would suggest framing either some of the programs/libraries with a few counts of 1st degree murder, and sending it to jail for life, where it can run for life in a nice little cell with it's own pet python. Would that work? It's probably a bit more work than a desirable solution, but if you don't need them running in the same space, it should work. Or have I completely missed the point (very likely given me). It's a good suggestion but I can see that being more trouble than it's worth. I wouldn't want to spend countless hours making sure that all those files, their dependencies, libraries and all that other jazz is in a jail on its own working smoothly, and even if I get it right upgrading components (e.g. security vulnerabilities) will prove to be a nightmare. Getting a second box is out of the question, for now at least, and while I thought virtualization might be the answer I see that FreeBSD only has guest support for Xen :-( Oh well, guess I'll post to freebsd-python to get some solution perhaps. Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Python threading - some ports depend on it, others break with it
Hi guys, I'm having so much trouble with this. I'm hosting a trac based project which is implemented in python and uses an sqlite db backend along with its python bindings. Now it turns out that pysqlite breaks badly (compiles and installs fine but chokes on import, see http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if python itself is compiled *without threading* support. However, on the same box I run a postgresql development and testing database and we have some triggers and other functions implemented in pl/python. Guess what? The compile of postgresql-plpython chokes upon configure if python is built *with threading* support. Running it seems to work fine, but there's a reason upstream put this check into configure because supposedly this is known to break things. Chicken and egg - one of my ports insists on python with threads enabled, the other port insists I use python without thread support. My workaround is to compile python without threading, install(or upgrade) postgresql-plpython, then recompile python with threading, install(or upgrade) trac and pray that plpython won't eat my dog when I use it. A really painful and error prone exercise, especially when an upgrade comes along (security or otherwise). I need both of these ports on one box and I'm not sure what to do to sort out this mess properly. Any ideas? What's up with Python's threading support on FreeBSD in any case, why is is broken? To get you an idea of what versions I'm running, the affected postgresql ports are postgresql-plpython-8.2.6 postgresql-server-8.2.6 for the trac dependencies the involved culprits are: py25-pysqlite-2.0.7_1 python25-2.5.1_1 python-2.5,2 sqlite-3.3.8 # peripheral I remember with python 2.4 I had the same endless issues over a year ago so it's not 2.5's fault. Oh, and btw, I'm running 6.2-RELEASE-p9 i386. Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPU usage 100% but no process hogging CPU
Kris Kennaway wrote: Gunther Mayer wrote: I don't see why my javavm, apache, postgres and/or radiusd would spawn such short lived processes. Come to think of it, I know radius might be doing just that, but how the heck would I go about finding out? top -H brings me no closer... Either increase the sample resolution or rule out other programs as the cause. Increasing sample resolution just increases the CPU usage of top itself but gives no more information about the real culprits :-( But I managed to solve my problem by reverting to and upgrading my SMP kernel. The system's back now with 15 minute load averages around 0.05 which is where it should be. What really remains a puzzle is what caused the bottleneck on my system running the GENERIC single CPU system. I actually went back to my daily cron emails in which it states that load average at 5am increased from around 0 to 1.0 somewhere between day 3 and day 4 after rebooting into freebsd-update's erroneously downloaded GENERIC kernel. It stayed around 1.0 until this morning when I reverted and rebooted. On even closer inspection, before doing freebsd-update I had an uptime of 202 days on that box. Even then there are some days when load average was 1.0 at 5am, I think the real culprit is my radiusd which probably sometimes spawns threads that chow 100% CPU until killed somehow. Having only one CPU available would of course exacerbate such a problem. Seeing that performance is back 100% I think I will wait for 7.0 to supercharge my system's threads. Anyways, thanks for the help Kris. Gunther I see that my java is using no less than 26 threads, thread usage not showing up might well be the problem. Interesting point you make about libthr. I had no idea about the different threading options available on 6.x and did some reading up on it but there's very little official documentation or recommendations about it. Upon investigation it turns out that all my core daemons (httpd, postgres, radiusd and java) are linked against /lib/libpthread.so.2 which afaict after limited reading is what you refer to as libkse. Is that correct? Yes. So I'm tempted to use libmap.conf to switch to libthr for all instances of libpthread, though I'm put off by some very recent reports (http://roy.marples.name/node/332) that this can cause some nasty problems. Do you think that's cause for concern? That bug report makes no sense to me. If they are using libmap correctly then *all* libpthread references are remapped and if there are missing symbols they will cause failure from the dynamic linker when the process is first executed, not random crashes during operation. Would you mind sharing your libmap.conf and/or symlink setup with the list as well as your experiences with libthr? See libmap.conf(5). Then again, as a first step I should really get my SMP kernel back as a first step... That will surely help. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
CPU usage 100% but no process hogging CPU
Hi there, I'm having some capacity issues on the FreeBSD 6.2/Core 2 Duo/2GB RAM server that I manage. For quite a few days now it constantly shows load averages of around 1 and a CPU usage of around 100%. Yet summing up the CPU usage of the individual processes running I hardly ever get to more than 5%, regardless of how long I watch top. A snapshot of my top output looks like this: last pid: 96102; load averages: 1.28, 1.15, 1.06 up 22+08:33:16 13:55:03 122 processes: 2 running, 119 sleeping, 1 zombie CPU states: 67.3% user, 0.0% nice, 32.7% system, 0.0% interrupt, 0.0% idle Mem: 474M Active, 974M Inact, 186M Wired, 68M Cache, 213M Buf, 93M Free Swap: 4064M Total, 4064M Free PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 635 root1 1220 27304K 2644K select 656:38 1.27% syslog-ng 844 www20 200 411M 300M kserel 360:13 0.00% java 837 user1 3 200 29048K 5672K kserel 34:30 0.00% radiusd 788 pgsql 1 960 13516K 3824K select 10:03 0.00% postgres 785 pgsql 1 1150 120M 7436K select 9:02 0.00% postgres 787 pgsql 1 80 120M 41112K nanslp 5:15 0.00% postgres syslog-ng is quite busy as I use it to capture logs of more than 50 remote sites. I have lots of slow queries in my postgres logs that I think are related to this bottleneck, though unoptimised queries and an ever growing amount of data are more likely to take the blame for that. High disk I/O in this regard could explain the high system utilisation, however. I found out that I've been bitten by the freebsd-update bug (http://security.freebsd.org/advisories/FreeBSD-EN-07:05.freebsd-update.asc) which replaced my SMP kernel with a GENERIC one and I'm taking corrective action early tomorrow morning, but surely even with just a single CPU the load average should never be as high? Where are those phantom CPU hogging processes? Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 going haywire
Ghirai wrote: Hello Gunther, Monday, May 28, 2007, 2:45:07 AM, you wrote: Hi there, My ath0 wireless interface is going crazy lately. In my logs the kernel keeps telling me May 28 01:26:28 greg ath0: link state changed to UP May 28 01:26:28 greg ath0: link state changed to UP May 28 01:26:28 greg ath0: link state changed to DOWN May 28 01:26:28 greg ath0: link state changed to DOWN while the wireless connection becomes completely useless. The first time this happened was 5 days ago when I got these messages every couple of minutes. Today it happened again but much worse than before: First 4 such messages every 3 seconds, then later 15/sec!!! This kept going for almost 2 hours while I tried to debug things over the wired interface, but I had no luck until miraculously it stopped its madness and came back to normal 15 min ago. No other hints in /var/log/messages... This this a sign of failing hardware? Or some other obscure bug in the ath driver? My signal is pretty solid at 25-30 S:N btw so it can't be that... Gunther Maybe someone is performing a deauth attack on your AP, in hopes of getting your password? Very unlikely since my wireless is actually unencrypted. Unless it's a DoS of course. How could I trace that? Tcpdump on the wireless interface on the ap shows nothing unusual. My laptop associates 100% with the same ap btw, also the card is completely useless now and I have to string a cable through my whole house... Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ath0 going haywire
Hi there, My ath0 wireless interface is going crazy lately. In my logs the kernel keeps telling me May 28 01:26:28 greg ath0: link state changed to UP May 28 01:26:28 greg ath0: link state changed to UP May 28 01:26:28 greg ath0: link state changed to DOWN May 28 01:26:28 greg ath0: link state changed to DOWN while the wireless connection becomes completely useless. The first time this happened was 5 days ago when I got these messages every couple of minutes. Today it happened again but much worse than before: First 4 such messages every 3 seconds, then later 15/sec!!! This kept going for almost 2 hours while I tried to debug things over the wired interface, but I had no luck until miraculously it stopped its madness and came back to normal 15 min ago. No other hints in /var/log/messages... This this a sign of failing hardware? Or some other obscure bug in the ath driver? My signal is pretty solid at 25-30 S:N btw so it can't be that... Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Spaces in SSID in /etc/rc.conf
Christopher Cowart wrote: On Mon, May 14, 2007 at 09:45:48PM +0200, Gunther Mayer wrote: Hi there, I got a low key server who is wirelessly connected to the net using an SSID that contains a space. In rc.conf I define the ifconfig line for configuration of my wireless interface upon bootup, but the entire line reads something like ifconfig_ath0=' inet 192.168.0.1 ssid my network ' No matter how I tweak the quotes (single then double, other way round, with lots of \\) I never get my interface to configure properly upon bootup and I need to get to the console to fix it up. I thought I knew shell syntax but this is beyond me or manpages... What's the right way to do this? One approach would be to navigate the series of function calls defined in /etc/network.subr. I just took a brief look, but it's not immediately obvious how many times you're going to have to escape exactly what to get the behavior you desire. Another option would be to make the file /etc/start_if.ath0, containing the line `ifconfig ... ssid my network`. This file would be sourced when /etc/rc.d/netif starts the network interfaces, before the rc variable ifconfig_ath0 is run. You can then omit the variable ifconfig_ath0 from /etc/rc.conf. For more hints, look in /etc/netif, /etc/network.subr, and /etc/rc.subr. Thanks for all your ideas guys, I really appreciate the help. Finally got some time to try all of your suggestions, though backwhacking (\) the space and/or the quotes makes no difference so I decided in the end to stop fighting the quoting wars and to just use /etc/start_if.ath0 which works perfectly. Not quite as neat as having everything live in /etc/rc.conf but it does the trick. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Spaces in SSID in /etc/rc.conf
Hi there, I got a low key server who is wirelessly connected to the net using an SSID that contains a space. In rc.conf I define the ifconfig line for configuration of my wireless interface upon bootup, but the entire line reads something like ifconfig_ath0=' inet 192.168.0.1 ssid my network ' No matter how I tweak the quotes (single then double, other way round, with lots of \\) I never get my interface to configure properly upon bootup and I need to get to the console to fix it up. I thought I knew shell syntax but this is beyond me or manpages... What's the right way to do this? Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
