Le 17/03/2015 12:40, Peter Serbe a ?crit :>> "is it feasible/are there any caveat" > Baseline is: not feasible. > The baseline is: only one samba per box. > You need to different IPs, which operate > independently from each other, as You can't > move the ports, where Your daemons are listening. > You would also need different daemons listening > on these two IPs.So even with two interfaces and bind interfaces only you cannot do it? Sad> Even if this was possible, You would not find > someone having done it here. It is against all > the recommendations, and this hacked installation > is likely to be not manageable. It is that far > away from the ordinary use case, that I would > advise to think for some different way to achive > Your goal. Whatever it was (as we don't have > gotten it by now...).Well? Having a VM just to split the DC from the file server seems a little overkill, so I guess I'll have to switch to Samba 4.2 in order to have a usable winbindd on the DC Regards,
On 17/03/15 13:15, S?bastien Le Ray wrote:> > Le 17/03/2015 12:40, Peter Serbe a ?crit : >>> "is it feasible/are there any caveat" >> Baseline is: not feasible. >> The baseline is: only one samba per box. >> You need to different IPs, which operate >> independently from each other, as You can't >> move the ports, where Your daemons are listening. >> You would also need different daemons listening >> on these two IPs. > > So even with two interfaces and bind interfaces only you cannot do it? > Sad > >> Even if this was possible, You would not find >> someone having done it here. It is against all >> the recommendations, and this hacked installation >> is likely to be not manageable. It is that far >> away from the ordinary use case, that I would >> advise to think for some different way to achive >> Your goal. Whatever it was (as we don't have >> gotten it by now...). > Well? Having a VM just to split the DC from the file server seems a > little overkill, so I guess I'll have to switch to Samba 4.2 in order > to have a usable winbindd on the DC > > Regards,Ah, but from my testing, winbindd on 4.2 works very similar to winbind, it still ignores most of the RFC2307 attributes and as I understand it, trusts still do not work. Why don't you buy a cheap refurbished PC and use that, after a quick search, I found that I can buy one for approx ?80 inc vat very easily, or if you only have a few users, there is always a raspberrypi 2 $35 Rowland Rowland
Le 17/03/2015 14:25, Rowland Penny a ?crit :> Ah, but from my testing, winbindd on 4.2 works very similar to > winbind, it still ignores most of the RFC2307 attributes and as I > understand it, trusts still do not work.Mmmm interesting. I've been looking for a while to 4.2 precisely for this reason (rfc2307 to get consistent UID on DC) and the commit I found was only a special switch passed to winbindd to inform it it was running on a DC, so there shouldn't be any difference, this is the same daemon. Did you fill a bug/talked to a dev about this?
Hi S?bastien, S?bastien Le Ray schrieb am 17.03.2015 14:15:> So even with two interfaces and bind interfaces only you cannot do it? SadI am by no means an *nix epert. Maybe it is possible - but I don't know anyone how ever talked about doing something like that. And given the _very_ limited resources, You had mentioned, I think it just won't work. Below I attach a 'top' screen shot from my Raspi 1B+ with one user logged in (namely me...). It acts as DC, uses the Bind DLZ-backend and runs VPN between my two sites. You'll notice, that RAM 512k RAM is extremely scarce. Thing will look better for the Raspi 2, but a cheap second hand PC is the better bet. A few days ago I saw an advertisment for a second hand Compaq PC with a 3 GHz Core2Duo and 4 GB RAM in it for 99?. (see Yourself: http://www.softwarebilliger.de/pc-computer/ ) You have to spend a bit more, if You want something, which pulls less energy. But here the use case is important again: Is it really allways on? If You want a perfect fit for Your needs, then You need to invest in researching the relevant PC magazines (for example).> Well? Having a VM just to split the DC from the file server seems a > little overkill,It might seem like that. However this is exactly what is typically done. Once You got Your first VM up and running, basically You can spawn as many VMs as You want. More or less.> so I guess I'll have to switch to Samba 4.2 in order to > have a usable winbindd on the DCIf I understood the discussion right, then the implementation of the protocols, that are forming the base on which winbind(d) is running, still is incomplete - without hope of a quick change. And therefore You will need separate DCs and file servers still for a long time. I remember however, that for really small installations the use of the DC as file server had been regarded as adequate, though not being an optimum solution. You might also want to reconsider, whether You really want a separate file server. But hacking two instances of Samba onto one machine, will cost You so much time, that it would be better, earning a few extra bucks in the saved time and to buy some hardware... - Peter.
Le 17/03/2015 15:40, Peter Serbe a ?crit :> Hi S?bastien, > > S?bastien Le Ray schrieb am 17.03.2015 14:15: > >> So even with two interfaces and bind interfaces only you cannot do it? Sad > I am by no means an *nix epert. Maybe it is possible - but I don't know > anyone how ever talked about doing something like that. And given the > _very_ limited resources, You had mentioned, I think it just won't work.Yes, RAM upgrade is mandatory, whichever solution is used anyway, I agree>> Well? Having a VM just to split the DC from the file server seems a >> little overkill, > It might seem like that. However this is exactly what is typically done. > Once You got Your first VM up and running, basically You can spawn as > many VMs as You want. More or less.I use VMs when I need them. Emulating a whole system just to isolate network interfaces /is/ overkill, no matter how you look at it. But anyway I guess I'll have to use some kind of container system to avoid whole stack emulation> >> so I guess I'll have to switch to Samba 4.2 in order to >> have a usable winbindd on the DC > If I understood the discussion right, then the implementation of the > protocols, that are forming the base on which winbind(d) is running, > still is incomplete - without hope of a quick change. And therefore > You will need separate DCs and file servers still for a long time. > I remember however, that for really small installations the use of > the DC as file server had been regarded as adequate, though not being > an optimum solution. You might also want to reconsider, whether You > really want a separate file server.What I really want is have something homogeneous, that is consistent UIDs, GIDs, homedir & so on (RFC2307) among dedicated file servers and mixed DC/file servers which seem to be impossible right now.
argh, forgot to attach the top output... when it does synchronize the load is considerably higher. The memory consumption is however more or less equal. ============================ top - 15:50:19 up 8 days, 3:03, 1 user, load average: 0,09, 0,22, 0,25 Tasks: 85 total, 1 running, 84 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,0 us, 1,0 sy, 0,0 ni, 98,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 494592 total, 393908 used, 100684 free, 29632 buffers KiB Swap: 0 total, 0 used, 0 free. 140432 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1968 root 20 0 108032 48720 29976 S 0,0 9,9 1:15.38 samba 1974 root 20 0 107492 39284 20552 S 0,0 7,9 11:43.28 samba 2054 named 20 0 93188 37872 15352 S 0,0 7,7 10:37.63 named 1964 root 20 0 108272 35676 16908 S 0,0 7,2 30:44.68 samba 1971 root 20 0 108204 33936 15184 S 0,0 6,9 18:25.77 samba 1970 root 20 0 107700 32596 13984 S 0,0 6,6 0:34.41 samba 1966 root 20 0 110604 32324 14224 S 0,0 6,5 0:22.09 smbd 1927 root 20 0 107064 30228 11664 S 0,0 6,1 0:06.04 samba 3604 root 20 0 95612 28860 10976 S 0,0 5,8 0:04.24 winbindd 1965 root 20 0 107392 28276 9692 S 0,0 5,7 0:03.65 samba 1969 root 20 0 107064 25456 6892 S 0,0 5,1 0:04.96 samba 1976 root 20 0 107064 23272 4708 S 0,0 4,7 0:33.16 samba 1994 root 20 0 110604 22456 4356 S 0,0 4,5 0:01.67 smbd 1973 root 20 0 107064 21984 3420 S 0,0 4,4 0:00.33 samba 1963 root 20 0 107064 21824 3260 S 0,0 4,4 0:00.02 samba 1967 root 20 0 107064 21824 3260 S 0,0 4,4 0:00.39 samba 1972 root 20 0 107064 21824 3260 S 0,0 4,4 0:00.02 samba 5560 root 20 0 42228 13372 11792 S 0,0 2,7 0:00.85 winbindd 1980 root 20 0 41680 12504 10920 S 0,0 2,5 0:06.44 winbindd 1975 root 20 0 35684 10168 9008 S 0,0 2,1 0:01.86 winbindd 2104 root 20 0 25964 9264 7668 S 0,3 1,9 0:12.26 sssd_be 5549 root 20 0 11616 5692 4964 S 0,0 1,2 0:01.37 sshd 2105 root 20 0 28556 5288 4520 S 0,0 1,1 0:08.38 sssd_nss 2106 root 20 0 16848 5012 4268 S 0,0 1,0 0:07.70 sssd_pam 2103 root 20 0 18176 4868 4000 S 0,0 1,0 0:26.83 sssd 5551 root 20 0 6692 4152 2816 S 0,0 0,8 0:00.52 bash 16594 root 20 0 5672 4084 3360 S 0,0 0,8 18:13.29 openvpn 5557 root 20 0 12556 2760 2288 R 1,3 0,6 0:32.77 top