GELI reliability
Hi, I'm curious about GELIs theoretical behavior when faced with errors, and also any experience anyone might have. As an example, if I run ZFS with raidz over X drives, then the zpool should have no issue surviving the complete loss of a full disk. Also, the familiar "FAILURE - READ_DMA" or READ_DMA48 errors from a disk having a bad day should also be no issue, certainly not an issue that would result in crash, or worse still, loss of data. What I'm wondering is how much worse off the data would be if I were to slide inn a GELI layer between the physical drives, and the zpool. That is, if I use GELI directly on the individual drives ( /dev/ada0, /dev/ada1 etc), then make a raidz pool on top of the .eli devices ( /dev/ada0.eli, /dev/ada1.eli etc). For READ_DMA type errors, I suppose GELI could just forward the same errors up the stack, and that'd be that, the errors wouldn't be any more severe than what I'd have anyway? One exception could be if GELI sector size is larger than disk sector size. Not being too familiar with GELIs internal workings, I'm not sure that has to be the case though. GELI sectors have a new IV pr. sector, but the crypto itself is still done in 128 or 256 bit blocks, so given a single faulty disk sector, the rest of the GELI sector could still be read and decrypted? Or are entire GELI sectors faulted if a (smaller) underlaying sector is unreadable? And finally, what if an entire drive dies a cruel and horribly death, all of it's data returning to the large bit bucket in the sky? Would GELI simply relay the same errors upstack to ZFS, so ZFS would be able to handle it as well as it would have without GELI? I've used ZFS over GELI in the past, but never had any hardware issues to see how it plays out. I'm considering deploying it for more stuff now, and reliability wise, from what I know, I could loose very little by using GELI, or it could be time to buy napkins, because the risk of a grown man crying while trying to mop up spilled bits from the floor is increased significantly. (backups should avoid the need for tears though, besides, I don't have a mop) Terje ___ 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: (no subject)
On 10. mars 2011, at 18.38, 6412037...@email.uscc.net wrote: > Does OpenBSD use the same kernel as FreeBSD? I think your question about the relationship between *nixes can best be answered by a 4487 × 29437 diagram, which can be found in several formats here: http://www.unix-diagram.org/ Terje ___ 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: FS of choice for max random iops ( Maildir )
On 16. sep. 2011, at 12:31, free...@top-consulting.net wrote: > Right now I defined an entire array of 8TB ( all 16 disks ) separated in two > pieces. 50 GB for FreeBSD to boot and the rest available to configure as > storage. ZFS will want to write to it's ZIL (zfs intent log) before writing to the final location of the data. Even if you're not waiting for the ZIL-write to disk (because of the controller ram), those writes will probably make it through to disk. That gives you twice as many writes to disk, and a lot more seek. If you want to take zfs for a proper spin, I'd like to sugget adding two small SSDs to the setup, mirrored by zfs. You can use those both for the ZIL, and also as cache, for the array. That's a fairly small investment these days, and I would be surprised if it didn't significantly improve performance, both for your benchmark, and real load. Note: you might be in trouble if you loose your ZIL, thus the doubling up. I *think* you can SSD a cache without risking dataloss, but don't take my word for it. Terje___ 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: FS of choice for max random iops ( Maildir )
On 16. sep. 2011, at 16:18, free...@top-consulting.net wrote: > Got a measly 74MB/sec. You can't ask for advice, get it, do something completely different, and then complain that it didn't work. Neither can you ask people to donate their time, if you won't spend yours. In other words: if you won't listen, there's no point in us talking. However: Don't disable ZIL. Just don't. It's not the way to go. If you want to know why, google will help. Also, you're making some assumptions, such as the ZIL being bad for performance. That's not always the case. ZIL-writes are a rather nice load for spinning metal storage. Even if you write through cache, that can give you a boost on your real world workload. Which brings us to the third bit. You're benchmarking, not trying real world loads. That's the load you'll have to worry about, and it's the load zfs shines at. Thanks to the ZIL (the thing you're trying to kill, remember?) you can convert seek heavy writes to sequential zil-writes, freeing up disk bandwith for concurrent reads. If you want to test before spending money, try what Svein said. Set up a small logical volume (preferrably smaller than your controller cache, if it's large enough), then try that as a dedicated zil-device. Never tried that, but worth a shot. Terje___ 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: FS of choice for max random iops ( Maildir )
On 16. sep. 2011, at 16:18, free...@top-consulting.net wrote: > zpool create data da1 > zfs create data/maildomains > zfs set sync=disabled data/maildomains Just for the archives... sync=disabled won't disable disable the zil, it'll disable waiting for a disk-flush on fsync etc. With a battery backed controller cache, those flushes should go to cache, and be pretty mich free. You end up tossing away something for nothing. You're getting about half the performance on a sequential write to the zfs, as you get with raw ufs. That makes perfect sense, doesn't it? Ufs writes raw, zfs writes to zil, then final restingplace forthe data. Account for the seeks between, and you're seeing what you should. Move the zil if you don't want both those sets of writes on the same array, or do what Svein said, and get funk^w logical. (a tad simplified, but I think the logic will hold. (yes, pun intended)) Terje___ 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: Regarding zfs send / receive
On 2. apr. 2013, at 13.44, Joar Jegleim wrote: > So my question(s) to the list would be: > In my setup have I taken the use case for zfs send / receive too far > (?) as in, it's not meant for this kind of syncing and this often, so > there's actually nothing 'wrong'. I'm not sure if you've taken it too far, but I'm not entirely sure if you're getting any advantage over using rsync or similar for this kind of thing. First two things that spring to mind: Do you have any legacy stuff on the receiving machine? Things like physically removed old zpools, that are still in zpool.cache, seems to slow down various operations, including creation of new stuffs (such as the snapshots you receive). Also, you don't mention if you're deleting old snapshots on the receiving end? If you're doing an incremental run every 15 minutes, that's something like 3000 snapshots pr. month, pr. filesystem. Terje ___ 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: ZFS partitioning
On 12. mai 2013, at 15:21, Roland van Laar wrote: > I see that all the disks get the same partitions, including swap and boot? > Why is that? And do I need those 5 boot and swap partitions? You don't need them, but there's a good chance you'll want them. Long story, short version: with raidz and mirror, you survive the loss of a disk. If you put boot on one, and that's the disk you loose, you're up shit creek, having chosen not to bring a paddle. ;) It's also not a lot to loose by putting it on all of them. For swap, there's also performance-reasons. Terje ___ 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: "swap" partition leads to instability?
On 26. mai 2013, at 10:58, "M. V." wrote: > But recently I heard from a FreeBSD expert that I shouldn't have swap > partition for my server, and having swap partition could make my server > unstable Any chance this could be a simple misunderstanding? That he objected to the thought of the server swapping on an SSD (or whereever), more than the idea of having the partition itself? If you're heavily swapping on an SSD with no redundancy, sooner or later it will kill your server. Generally though, havin too little memory will also give issues. ;) I usually recommend viewing swap like you view filesystems. If you don't want downtime or dataloss when it dies, plan for failiure, and use gmirror or zfs mirror and zvol. Terje ___ 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: Possibly OT: NFS vs SMB performance
On 5. juli 2013, at 18:18, Andrea Venturoli wrote: > Is this normal in your experience? Did you do them in that order, or did you do the smb (slow) one first? If the slow was first, I'm thinking caching on the server could be a major factor. Terje ___ 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: 2 lines
On 29. juli 2013, at 18:38, "Zyumbilev, Peter" wrote: > Not sure what is the best way nowadays to get own /24 or at least /26 ? I don't think you ever said if this was two links from the same provider, or two different providers. That's a huge factor in what your options are. You'll have a hard time doing BGP-based failover with a /26. It's just too small a route to be announced globally. This stuff isn't just a technical question, but also one of policy and politics. In order to get to a proper solution, your best option is probably to give the provider(s) a call, and explain what you'd like to do. Depening on a lot of things, one option could be to have the provider owning the IP(s) tunnel it over the other link durin fault. Hard to say if they will, so you really nedd to talk to them. In the meantime, DNS-failover is a lot better than nothing. Terje ___ 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: Archiving a log file
On 4. aug. 2013, at 12:54, Frank Leonhardt wrote: > The program writing the log is actually called flubnutz and it doesn't play > nice with newsyslog, reopen handles on a signal or anything else Then you're out of luck for normal rotation. No matter if you rename the file, or even delete it, it'll keep writing to the same file (the moved file, not the same filename). I suppose your options are to either restart it to have it reopen the file, or if that's not desirable for whatever reason, look see if it'll play nice if you put a named pipe where the logfile is supposed to be. Then you can handle data as you'd like from the pipe. Terje ___ 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: Terrible disk performance with LSI / FreeBSD 9.2-RC1
On 8. aug. 2013, at 00:08, Frank Leonhardt wrote: > As a suggestion, what happens if you read from the drives directly? Boot in > single user and try reading a Gb or two using /bin/dd. It might eliminate or > confirm a problem with ZFS. If not too inconvenient, it'd be very interesting to see what'd happen if you were to physically disconnect (data and power) 5 of the 6 drives, then boot and dd from the remaining disk to /dev/null. Then repeat with another drive. You could boot from USB to leave the system itself otherwise untouched. The reason I'm suggesting is that I'm wondering if this can be down to a power or cable-issue, locking things up or causing retransmits, etc. Not sure if this would always be logged, others might be able to enlighten that issue. Terje ___ 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: sysvipc only for one jail
On 13. aug. 2013, at 06:14, Shane Ambler wrote: > If you missed the change, 9.3 is implementing shared memory using mmap. But still using sysvipc for some locks/mutexes, so doesn't allow you to run "sysvipc-free". Terje ___ 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: sysvipc only for one jail
On 12. aug. 2013, at 19.46, Trond Endrestøl wrote: > If you start the jail manually using jail(8), then /etc/jail.conf > comes into play, whereas the lines in /etc/rc.conf is used during > automatic startup of the jails when the host is rebooted. The whole > arrangement seems unnecessary redundant, and I truly wish this can be > merged sooner rather than later. It *is* unnecessary redundant. If you're using /etc/rc.conf to define the jails, then start them with: /etc/rc.d/jail start jailname That is, if you're mostly using /etc/rc.conf to define the jails, then start them manually using that as well? Problem solved? Terje ___ 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: trouble with PostgreSQL 9.2 on FreeBSD 10.0-CURRENT: superuser can not autheticate anymore with md5 password hash set
On 13. aug. 2013, at 16:30, "O. Hartmann" wrote: > What is going wrong? Are you unable to connect, or do you get an error message? If you do, what is it? Terje ___ 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: VPN where local private address collide
On 16. aug. 2013, at 19:17, Frank Leonhardt wrote: > Has anyone actually done this, and if so, how? This is wrong on so many levels, and you'll have to work around all og them. Yes, you can use nat, but what about adress-resolution? And so on. If it's a specific thing you need to work - a spesific server for example - nat can work, but if you need general bridging, best to avoid conflicts. Note that there are alternatives, such as L2-bridging rather than L3. If you explain a bit more of the setup, and what you need to work, it'd be easier to suggest something. Right now, we know bits of the setup, but not really what problem(s) you're trying to solve. Terje ___ 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: VPN where local private address collide
On 17. aug. 2013, at 12:42, Frank Leonhardt wrote: > The setup is basically as described and the desired outcome is to NAT "the > other end" so the addresses appear different. That's a solution to a problem, but I don't yet know what the problem is, which makes it harder to give any advice. Do you need "everything" to work in both directions? If so, then what is "everything"? Say both networks are at 192.168.0.0/24, and you remap so network A is available as 192.168.1.0/24 in network B, all machines at the same last octet (you can do that), and fix DNS for it. All good right? Well, it's not always that simple. Say you have a server running at 192.168.0.5 in network A, available at 192.168.1.5 in network B. A client connects (successfully) to it, ask for some data, and the server says "Get the data at 192.168.0.5:45756". Now the client will try to connect to that ip/port in network B, rather than following DNS for the IP that goes over the VPN and through the NAT, and get nowhere. You first hearing of that can be someone saying "The Foo-server is broken". You've just layered hack on top of hack, so you don't initially know if it's the user, his computer, the server, the VPN, the NAT or DNS, an incompatible protocol that doesn't like the setup, or the weird routing you'll have to set up. If you're looking at this as an easy fix to reach a specific server or service, by all means. But if you're looking at this as a general solution to bridging two networks, then just don't do it. Save yourself the grief, because if this works at all, it's down to luck, and even if you're get lucky now, you might not stay lucky. What happens if you add VoIP to the mix in two years? Or teleconferencing in three? Basing network-design on present and future luck is just going to give you more grief that I than I'd wish for anyone. Terje ___ 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: VPN where local private address collide
On 17. aug. 2013, at 16:37, Frank Leonhardt wrote: > This is just the sort of problem Google will have when it buys Facebook :-) Probably not. If Google were to buy Facebook, I'm confident they'd be able to renumber their networks if they have to. > Your explanation of the foul-up possible with NAPT is well made, although not > really talking about the kind of NAT used on Home/SME routers (one public > address hiding many private one) - I'm thinking of Basic NAT - one-to-one > replacement, not one-to-many. (i.e. static address assignment). All the > router (or firewall) needs to do is swap the IP address in the header as it > passes through, and swap it back when it returns. The two hosts shouldn't > notice a thing. That's a good theory. In reality, it's much more complicated. What about SSL/TLS for example? How would the router swap the header in an encrypted session? (That's a likely scenario with blth VoIP, teleconferencing and ftp over ssl btw). Swapping headers is also a bit outside the scope of NAT, and over to application level gateway. I've seen probably hundreds of attempts at such solutions, most didn't work at all, and few - if any - worked well. > FWIW it works pretty well without NAT if you can avoid address conflicts, and > in a small installation its possible. But consider this really trivial > example: If you're fine with the way it works without conflicts, why not just move things around? Change statically configured IPs, and narrow the DHCP scopes to avoid conflict? > The obvious answer is IPv6, of course. I'm surprised no one has mentioned it > yet. You seemed dead set on not renumbering the networks, and moving to IPv6 would not only be just that, but also be harder than just renumbering IPv4-nets, so you answered that question for us already. > mpd does handle NAT (Section 4.14 of its manual). It doesn't go in to great > detail execept to say it uses ng_nat, which in turn uses libalias (like > natd). Looking at the ng_nat 'C' interface, NGM_NAT_REDIRECT_ADDR sounds like > what I'm after but it all looks geared to NAPT (which is, I guess, what most > people use NAT for). And I've got this nagging feeling that ipfw is going to > be involved somewhere, just to make it really tricky. If you do insist on shooting the networkowner(s) in the foot, pf would probably do fine for the NAT. Best of luck on your adventure sir, you'll need it. If not today, then some day ahead. Bring a towel. Terje ___ 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: VPN where local private address collide
On 18. aug. 2013, at 12.20, Frank Leonhardt wrote: > I'm not sure that TLS would cause more problems than any other packets, but > as you point out, the exercise is bound to be full of pooh traps as yet > undiscovered. FTP should be interesting, for a start. But for most things, > why would swapping an IP address in the packet header cause any kind of > problem as long as it was done consistently? I was cutting corners and trying to keep the reply short (was on cellphone at the time), and I think the word headers might have lead to some crosstalk. For TCP/IP itself, just consistently swapping the IP would solve the problem. That'd fix a lot, and things like like ssh and http should work fine with that. If we look at other things though, like SIP, it's not that easy. I'm using SIP as an example just because it illustrates the point nicely, and I know it well. For SIP, you'd have the IP in multiple places: TCP/IP - the connection to the server. SIP - The application protocol RTP - Payload in the application protocol, carrying media-metadata Now, you'd get the connection to the server (TCP/IP), but for registering against the SIP-server, the client would include it's IP in the SIP-layer as well, in a http-like header. It'd tell the server where it would want to be contacted for things like incoming calls. Initially this would point to the clients perspective of the IP, and not to the IP it were to carry after NAT. That is, the client would be able to register, but for incoming calls the server would try to contact the IP in the wrong place. For placing calls, you'd also have information about where media-streams should go in RTP, both IP and port numbers. This would also carry wrong information if you're merely changing the IP/port in TCP/IP-layers. Both of these can be resolved wither in the router/firewall/NAT-box, or worked around on the server, but it's not pretty by a long shot, and it's completely avoidable if you can avoid the NAT. > There are lots of corporate networks on 10.x.x.x, and I'm told this kind of > caper is used to sort them out when they collide. Paying for a Cisco VPN > could easily work out cheaper than reconfiguring a large corporate LAN, but I > don't have the budget for either. This kind of thing *can* be used to sort out colliding subnets, but that doesn't mean it *should* be used to resolve the issue(s). You mentioned that a Cisco-guy said this would work, and explained details of how to do it. I'm thinking that the same Cisco-guy could also give details on how to drop a rack full of Juniper-equipment out of a 10th floor window, in order to replace it with Cisco-gear. It's quite possible to do that, but again, that doesn't mean you should. I think the gist of the issue here is that you have a problem, and you're (correctly) thinking you can solve a lot if you NAT the two networks together. That's not wrong, it's completely true. You can get a lot to work in that way. Then you also have some random-looking guy on a mailing-list telling you that "Yes, you can do that. But you shouldn't". I get how hard it can be to take that kind of advice, especially when you know and have been told that it's quite possible. If you really, really want to explore that route, then here's one way to go about it: Use the VPN just to get the link up, don't worry about using NAT with MPD. It's nice to keep all of the nat/firewall-bits in a single place, and pf is a good solution to it. If you're running the VPN off of the primary gateway, this should be fairly straight-forward, and you should be able to use something like this: pf.conf on gateway/vpn-endpoint in lan_a: lan_a = "192.168.0.0/24" lan_b = "192.168.0.0/24" vpn_a = "192.168.1.0/24" vpn_b = "192.168.2.0/24" binat on $vpn_if from $lan_a to any -> $vpn_a pf.conf on gateway/vpn-endpoint in lan_b: lan_a = "192.168.0.0/24" lan_b = "192.168.0.0/24" vpn_a = "192.168.1.0/24" vpn_b = "192.168.2.0/24" binat on $vpn_if from $lan_b to any -> $vpn_b The VPN-tunnel itself could ignore any concept of the conflicting 192.168.0.0/24-range, and simply deal with 192.168.1.0/24 being on one end, and 192.168.2.0/24 on the other. If you're standing in lan_a, and your local address is 192.168.0.182, and you'd like to reach 192.168.0.17 in lan_b, you'd talk to 192.168.2.17. In lan_a, the conneciton would be seen as 192.168.0.182 -> 192.168.2.17. Crossing the lan_a VPN-endpoing going into the tunnel, it'd get rewritten to be 192.168.1.182 -> 192.168.2.17. Crossing the lan_b VPN-endpoint going into lan_b, it'd get rewritten to be 192.168.1.182 -> 192.168.0.17 You'd then hit the right server. The response from 192.168.0.17 (in lan_b) would get routed back over the VPN-tunnel, since it's sent to 192.168.1.182. That is, in lan_b the response would be 192.168.0.17 -> 192.168.1.182. Crossing the lan_b VPN-endpoing going into the tunnel, on the way back to lan_a, it'd get rewr
Re: VPN where local private address collide
On 18. aug. 2013, at 02.43, Adam Vande More wrote: > > What about SSL/TLS for example? How would the router swap the header in an > > encrypted session? > > Same as it would any sessions since only the payload is encrypted. What > Frank calls basic nat, most people call static nat(at least people who have > read enough Cisco docs) and it works just fine. Also you are confusing > headers. The point I was aiming for was that even if you were to swap the IPs in the IP-header on the gateway, some protocols still reference the IPs inside the TCP-payload, and while you can rewrite that on a NAT-box using an application level gateway, you can not do that if the session is using SSL or TLS. I was referring to headers *inside* the SSL/TLS-layers. I thought that was obvious, but I see I might not have been clear enough. Yes, you can often still resolve it on the server, but just how messy does one want to get stacking workaround on top of workaround, just to avoid renumbering the network? Terje ___ 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: VPN where local private address collide
On Aug 20, 2013, at 8:33 AM, Adam Vande More wrote: > and while you can rewrite that on a NAT-box using an application level > gateway, you can not do that if the session is using SSL or TLS. > > Complete BS. This seems to come down to a misunderstanding in the examples drawn up, and of TCP/IP-headers (outside the SSL/TLS encryption) and SIP-headers (inside the SSL/TLS encryption). Noone is arguing that SSL/TLS would give any troubles with changing TCP or IP-headers during NAT, and that part seams clear both to the OP and myself. It's the SIP-headers inside an encrypted SSL/TLS-session that a NAT-layer wouldn't be able to change, even if it wanted to (and arguably outside the scope of NAT). > I was referring to headers *inside* the SSL/TLS-layers. I thought that was > obvious, but I see I might not have been clear enough. > > Not clear in the least. Expanding on what is so difficult about might do a > lot of us some good. Read up if you'd like: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg268807.html I'm not quite sure what part isn't clear, so please email me if there is anything. Preferrably off-list, this tread seems to be stearing towards you calling BS based on a misunderstanding, and that's probably not adding a lot of value to -questions. > Yes, you can often still resolve it on the server, but just how messy does > one want to get stacking workaround on top of workaround, > > Despite your protestations to the contrary, NAT and SIP work quite weil > together in basic configurations including TLS and the OP's scenario. I > can't explain your difficulties but perhaps when you aren't at a mobile > device you could answer a question in depth. > > > The server would register that the phone is available at 192.168.0.200 > (locally, in lan_b), while the server would actually need to send to > 192.168.2.200, in order to reach 192.168.0.200 in lan_a. > > > Exactly how this would behave depends on a lot of factors, but you'd quickly > end up with a situation in which the phone *appears* to work, can register > against the server and call out (both client-initiated), but where incoming > calls just don't work (sent to 192.168.0.200 in lan_b, rather than in lan_a). > > Could you could post your config to demonstrate what you are doing > incorrectly? I'm not doing anything incorrectly or otherwise, and I'm not having any difficulties with anything. I drew up an example, to illustrate a point. And I know very well that NAT and SIP with TLS *can* work quite well in such a setup. In fact, I'm even arguing it. If the server does the right thing in a non-standard scenario, things can work quite well out of the box even. However, if the server doesn't do the right thing in this scenario, you might have a good bunch of debugging on your hands. I've never argued that you can't get it to work, I'm arguing that the farther away from standards you go, the more you might break and have to fix or find workarounds for. Terje ___ 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: FreeBSD 8.4 Boot failure
On 25. sep. 2013, at 06:59, Tyler Sweet wrote: > I tried reinstalling the boot blocks from both > the fixit live filesystem and also mounting zroot and using the files > there in case they were different. Disclaimer: I haven't gotten (enough) morning-coffee yet, but... Disclaimer 2: at times tracking how zfs-booting is done in the different versions can be a bit tricky. This is a moving target, and I've lost track of the 8-branch. That said, assuming you have the correct bootcode (gptzfsboot), here's what might have happened: You installed 8.2, with a loader supporting zfs. Then you upgraded your /boot-stuffs, and bootcode on disk (correctly), but got left with a loader without zfs support. Then tried to upgrade the bootcode, but you're still left with a loader not supporting zfs. If I recall correctly, then the zfs-bootcode for 9+ will use "zfsloader" (supporting zfs and built by default), while earlier versions depend on "loader" with zfs support (built without by default). If that's the case, you could dump LOADER_ZFS_SUPPORT into /etc/make.conf and rebuild/reinstall it, or install /boot/loader from the fixit (if it has zfs support in 8.4). That's my first thought at least... If that doesn't fix it (remember backups of any files you replace or upgrade), it'd be interesting to see the output of: ls -l /boot/*loader /boot/*boot On the /boot you're using. Anything that didn't get built or installed? Also, did you snapshot your zfs before upgrading? Could be a working /boot/loader there, which might be the easiest way to get the system up, before rebuilding with ZFS-capable loader... if I'm right, which isn't a given (ref disclaimers). Terje ___ 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: New system - go for 9.1+upgrade - or go for 9.2-RC4?
On 25. sep. 2013, at 09.00, Ewald Jenisch wrote: o) Will upgrading kernel/system using > svn co svn://svn.freebsd.org/base/stable/9/ /usr/src > bring a 9.2-RC4 installed system up to date once 9.2 final is released? Two options: base/stable/9 - track 9-STABLE base/releng/9.2 - track 9.2-security branch The former is more of a moving target, while the latter is 9.2-RELEASE, but gets security updates. Also, rather than using svn://, I'd use https://, and pick a server from this list: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn-mirrors.html Terje ___ 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: How to ask a DNS resolver listening on a different port than the tcp/udp 53
On 27. sep. 2013, at 20:20, Laurent SALIN wrote: > I've got a "bad" solution, use unbound on the second VPS and maybe tell > him to ask the 1rst VPS on the unusual tcp/udp port Why is that a "bad" solution? You'd cache locally, which is often considered a good thing? Granted, it's a bit of a weird setup, but still. Terje ___ 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: How to ask a DNS resolver listening on a different port than the tcp/udp 53
On 28. sep. 2013, at 00:03, Frank Leonhardt wrote: > If I understand the way it works correctly, the resolver pulls a list of the > NS and hard-sets the port number for each to 53 (via a manifest constant) . > See libc/resolv/res_init.c. All you need to do(!) is change this to a value > of your choice and recompile libc Sorry, but this is startin to look a lot like a complicated solution to a problem that isn't really there... Why not just point from resolv.conf to localhost, run a caching and/or recursive dns-server there, and point it whereever? As far as I can tell, that'd solve everything, add caching, and let it all be controlled from the config of the DNS-server? Terje ___ 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: How to ask a DNS resolver listening on a different port than the tcp/udp 53
On 28. sep. 2013, at 15:50, Frank Leonhardt wrote: > Given that BIND can happily listen on ports other than 53 and OpenBSD allows > a port to be specified against each nameserver in resolv.conf, it does not > seem an unreasonable question to me. Just to avoid any misunderstanding... Not sure if I misunderstood what you're trying to do, but the way I recall it, you have two boxes, one running with one recursive and one authoritative nameserver, and you wanted a second box to quey the recursive nameserver on the first box, which is running on another port than 53? Given your setup, that's a valid question. It's getting down to patching the resolver I felt was a bit overkill, and a possible source of future pain. How to solve it is a perfectly valid question. Personally I'd just think it cleaner to solve it by running a caching resolver on the second host (on port 53), that could forward queries where you'd like, rather than patching or usik firewall redirects. Terje ___ 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: Geli and ZFS
On Oct 9, 2013, at 6:43 AM, yudi v wrote: > Generally, it's recommended to let ZFS manage the whole disk if possible, > so I was wondering if the second option is better. > I will be using couple of 3TB HDDs mirrored for data and want to encrypt > them. IIRC, there is/was a major performance-difference on Solaris between using ZFS on a partition, or a whole disk. FreeBSD is happy with either. The two alternatives you mentioned were: ZFS over GELI over disk and ZFS over GELI over ZFS over disk While ZFS wouldn't get the raw disk in setup #1, the left-most ZFS wouldn't get it in the second scenario either. > I am hoping someone with an in-depth understanding of ZFS will be able to > offer some insight. What I usually do and recommend is using GPT with labels for the partitions you'll put GELI/ZFS on. There's a couple of different reasons for this: * It'll let you create your zpool on /dev/gpt/label, which will make it easy to find even when the device moves (harddisk-renumbering, changes from internal ATA to USB enclosure… ) * You don't run things through ZFS twice. * The disk is fully encrypted. * etc Terje signature.asc Description: Message signed with OpenPGP using GPGMail
