[00:08] <MACscr> for those that manage a lot of servers that do not normally have an email server on them. how are you typically handling sending emails from root? just installing postfix? seems a little heavy for the need, but i could easily be wrong
[05:34] <wehde_> does anyone know how to sync apt-cache across servers?
[08:45] <lordievader> Good morning.
[11:44] <jamespage> caribou: hey - around? we're both looking at haproxy problems so might be work chatting on solutions - also been discussing with the debian maintainer as to approach to nbproc > 1
[11:48] <Darkyyy> hello ppl
[16:09] <impermanence> Is it difficult to configure postfix or mail to send email to remote clients?  I thought all I would have to do is the minimal install of both and I'd be good but mail seems to only like to be sent from a local user to a local user.  What am I missing?
[16:13] <shauno> usually just 'dpkg-reconfigure postfix' and pick the right topology from those offered (bad advice for a proper mailsite, but works really well for a satellite site).  although there's things like ssmtp that cater more directly to such uses now
[16:21] <impermanence> @shauno Okay, so I do need to manually configure a bunch of stuff…
[16:21] <impermanence> @shauno I don't care about sec.  It's all internal cloud.
[16:37] <Walex> impermanence: that's a bit optimistic...
[16:37] <impermanence> @Walex how so?
[16:37] <impermanence> @Walex oh you mean my cloud comment?
[16:38] <Walex> impermanence: "internal" sometimes is not that internal...
[16:38] <impermanence> @Walex you're right.
[16:39] <Walex> impermanence: anyhow for that 'postfix' stuff a satellite config or 'ssmtp' is good as <shauno> said. the config file will be identical on all hosts: just pointing to the "smart host"
[16:40] <Walex> impermanence: note that sends email to a remote server, not a client, but I guess that was a mistype.
[16:40] <impermanence> @Walex it was.  the client in this case is the server.  i never know anymore honestly.
[16:41] <Walex> impermanence: something like this looks good: https://www.dnsexit.com/support/mailrelay/postfix.html
[16:42] <Walex> impermanence: similar here: http://www.certdepot.net/smtp-configure-a-mta-with-a-smart-host/
[16:45] <Walex> last time I did this I used 'esmtp' rather than 'ssmtp' can't remember why
[17:01] <herrkin> hello community, I have been having trouble with permissions so badly that I think it has to be something I am not understanding of ubuntu.
[17:02] <herrkin> first it was in apache, I decided to forget about it, I had a symlink to a folder in my home, if I was logged in in the shell it worked perfect, the second I logged out the os it broke saying nobody had permission to go to the page.
[17:02] <herrkin> something oddly similar is happening to me with pm2
[17:02] <TJ-> herrkin: Encrypted home directory maybe?
[17:03] <herrkin> yes, but in the case of apache the apache user is the same as in my home directory
[17:03] <herrkin> there should be no problem, still there is.
[17:03] <herrkin> that was only to illustrat
[17:03] <herrkin> pm2 is giving me a similar error
[17:04] <herrkin> it only works if i am logged into the system
[17:04] <herrkin> if I log out it kills itself
[17:04] <herrkin> if I configure the startup script it never execute
[17:04] <herrkin> I have been arround this for a week, its driving me crazy.
[17:05] <TJ-> encrypted home will make a big difference, since when you log-out the encrypted user home directory is unmounted and the files disappear
[17:05] <herrkin> is there a way to make it keep it mounted?
[17:05] <herrkin> or make another user mount it so it can use it?
[17:06] <TJ-> No. Don't use encrypted user home if you intend a service to access it
[17:06] <TJ-> Or alternatively, move the served content to another directory outside the user's home
[17:06] <teward> i was about to say that lol
[17:06] <teward> :p
[17:06] <jrwren> use byobu to fake always being logged in?
[17:07] <herrkin> byobu?
[17:07] <jrwren> tmux or screen?
[17:07] <jrwren> it leaves a shell running in your homedir. might be enough to prevent the unmount.
[17:07] <jrwren> i don't know how the system decides to unmount the encrypted home
[17:08] <TJ-> In which case why bother encrypting it?
[17:08] <TJ-> jrwren: when there's no user logged in
[17:08] <herrkin> remember I told you I didnt want them to access the files mounting the disk in another machine?
[17:08] <TJ-> the mount/umount is done by pam_ecryptfs
[17:08] <herrkin> thats why :D
[17:08] <jrwren> TJ-: bothering only for FBI raid protection.
[17:08] <TJ-> herrkin: your design is broken then. You can't have it both ways.
[17:09] <herrkin> then its just not possible to deny people accessing files?
[17:09] <jrwren> herrkin: I understand your requirements and I think they are reasonably as long as you are OK with the drawbacks.
[17:09] <herrkin> yeah but I am ignorant about the shell you are sugesting
[17:10] <herrkin> how do I do it?
[17:10] <herrkin> it might be it.
[17:10] <jrwren> herrkin: apt-get install byobu, then when you ssh, run byobu
[17:10] <herrkin> if the home unmounts when I log out then I need a way to keep it alive forever
[17:10] <herrkin> I guess
[17:10] <herrkin> ok just like that?
[17:10] <herrkin> nothing else needed?
[17:10] <jrwren> to logout, don't close byobu by exiting the window, instead, detach with ctrl-a, d, then exit the ssh.
[17:11] <herrkin> oh.. its like a second layer
[17:11] <jrwren> herrkin: byobu is a wrapper around gnu screen or tmux. if you aren't familiar with them, i highly recommend you become so. they are valuable tools.
[17:11] <herrkin> I just keep it running in the background
[17:11] <kirkland> fyi, there's a video demo at byobu.co
[17:11] <jrwren> yes, keeps shells running in bg
[17:12] <herrkin> I will go see it. thanks.
[17:12] <jrwren> kirkland: does it keep an encrypted home fs mounted?
[17:12] <kirkland> jrwren: yes, until you logout all sessions
[17:13] <jrwren> there ya go herrkin. exactly what you want
[17:13] <herrkin> wow that term is amazing.
[17:14] <herrkin> I can have multiple windows, pretty good
[17:14] <impermanence> @Walex Oh hey thanks man.  I'm actually kind of surprised at how complicated this is.
[17:14] <jrwren> herrkin: valuable tools? :)
[17:15] <herrkin> ok I will try it, I will be reporting the results
[17:15] <acmehandel> I set up psad on my server and got flooded with messages within minutes.
[17:16] <acmehandel> how do I set it up to where I get 1 summarized message per day?
[17:16] <herrkin> still there is a problem
[17:17] <herrkin> how do I make it start up?
[17:20] <herrkin> jrwren, I think I might have broke something up
[17:20] <herrkin> because I could go in and out before
[17:20] <herrkin> pm2 list and it keept on working
[17:20] <herrkin> no matter if I was logged in or not
[17:21] <herrkin> when I tried to make it start on boot up it screwed that functionality
[17:27] <herrkin> I tried to do ctrl-a,d as suggested, didnt work, it still kill pm2 at logout
[17:27] <herrkin>  maybe it also kills byobu
[17:28] <herrkin> it may kill everyting that the user is executing
[17:28] <herrkin> I don't really know
[17:38] <herrkin> TJ-, so you think I should definitely have it without encryption.
[17:38] <herrkin> I would lose the protection of the files :(
[17:56] <herrkin> wow, everybody is gone.
[17:56] <teward> herrkin: or busy or patience, it's lunch at some places
[17:57] <teward> herrkin: TJ- has indicated that you have two goals:  protect files, but let services access them.
[17:57] <teward> herrkin: Either move those specific files out of the encrypted home directory and into unencrypted space where it can be accessed by services
[17:57] <teward> or leave a login session running, and your entire home is 'decrypted' per se
[17:58] <herrkin> I tried what you told me
[17:58] <teward> If you're exposing the files to a service anyways, securing the files from being accessed is already out the window
[17:58] <herrkin> no luck
[17:58] <herrkin> it seems the time l
[17:58] <herrkin> I log out it kills byobu too
[17:58] <herrkin> when I log back in its like I have never logged in before
[17:59] <patdk-wk> well, if your using encrypted home folders, ANYTHING that runs as you, should die
[17:59] <patdk-wk> as your home folder will become encrypted when you logout
[18:00] <herrkin> yes, is there a way I can have a session running forever? like a service session?
[18:00] <patdk-wk> servers and encrypted home folders, genrally don't mix
[18:00] <teward> your only option in this case is: (1) don't use encryption, or (2) put the web doc root into unencrypted space
[18:00] <herrkin> I thoght that was what happened with apache and others
[18:00] <teward> agreed with patdk-wk
[18:00] <patdk-wk> FDE and servers mix, but is normally a pain to manage
[18:01] <patdk-wk> what do you mean apache and others?
[18:01] <herrkin> then how could i protect some folders that can only be accessed by services?
[18:01] <teward> herrkin: define 'protect'
[18:01] <herrkin> nobody can grab the code
[18:01] <patdk-wk> encrypted? impossible
[18:01] <teward> herrkin: too late - it's already exposed to the *net if you're using Apache to access it
[18:02] <teward> (theoretically)
[18:02] <herrkin> yes but apache delivers its version of the code, not everything
[18:02] <teward> point missed
[18:02] <herrkin> I mean it serves results, not code
[18:02] <herrkin> yes
[18:02] <teward> herrkin: in theory? set up ACLs for the folders and files
[18:03] <teward> but that can be painful to maintain over time
[18:03] <herrkin> ok lets just resume.
[18:03] <patdk-wk> hmm?
[18:03] <patdk-wk> lets say, your running a php site on your server
[18:03] <herrkin> ok
[18:03] <patdk-wk> and you want to protect the php files from exposure
[18:03] <patdk-wk> it's not possible
[18:04] <patdk-wk> all it takes is ANY vaunerability in anything that runs under that user, and your exposed
[18:04] <teward> gbah lag
[18:04] <patdk-wk> so any flaw in your php code
[18:04] <patdk-wk> and your exposed
[18:04] <teward> (the last part I was going to say is "That doesn't actually 'hide' the code to the world, really)
[18:04] <teward> patdk-wk: thanks for adding that on, lag / network weirdness disconnected me for a second
[18:04] <herrkin> ok
[18:04] <teward> herrkin: if you want the code to NOT be visible to the world, you don't have it served by a web server or service
[18:04] <patdk-wk> acl's, apparmor, ..., nothing is going protect against that
[18:04] <teward> ^ that
[18:05] <herrkin> so thats a crap lol.
[18:05] <teward> herrkin: you can protect it from other local users, possibly, accessing it, but NOT if it's being served to the web
[18:05] <teward> (I was imprecise earlier)
[18:05] <patdk-wk> generally this is why people go with multible levels
[18:05] <teward> mhm
[18:05] <herrkin> the thing is that I deliver a black box to the client, in theory they should not be allowed to grab anything from the machine
[18:05] <patdk-wk> backend api, frontend webserice
[18:05] <patdk-wk> and nothing you care about on the frontend
[18:05] <patdk-wk> it will limit that attack pretty well, not perfect, but make it damned hard
[18:05] <herrkin> but nothing is stopping them from taking the hdd and mounting it in another maching
[18:05] <teward> herrkin: FDE
[18:05] <herrkin> getting the files and selling my software
[18:05] <teward> full disk encryption would 'prevent' that, per se
[18:06] <teward> but, it's painful to manage
[18:06] <teward> to quote patdk-wk...
[18:06] <teward> [2015-11-09 13:00:47] <patdk-wk> FDE and servers mix, but is normally a pain to manage
[18:06] <herrkin> yes but I would still need to give them the key if they need to reboot the machine
[18:06] <herrkin> thats silly
[18:06] <patdk-wk> no
[18:06] <patdk-wk> why is it silly?
[18:06] <patdk-wk> I do it
[18:06] <patdk-wk> and I do it automated, most reboots are automatic
[18:06] <herrkin> give the encryption key to them?
[18:06] <patdk-wk> yes
[18:07] <herrkin> why would you do that?
[18:07] <patdk-wk> heh?
[18:07] <herrkin> if thats what you are avoiding in the first place?
[18:07] <patdk-wk> hmm?
[18:07] <patdk-wk> how do you unencrypt a system that is encrypted without a key?
[18:07] <herrkin> I mean if they have the encryption key they can get everything from the system, cant they?
[18:07] <teward> herrkin: it sounds like you are giving a client a black box, but then not wanting them to be able to use it / install it / reboot it without calling you to come in and reboot everything
[18:07] <herrkin> its like its not encrypted
[18:07] <patdk-wk> herrkin, heh? I have to give it the key on each boot
[18:08] <patdk-wk> no exceptions or work arounds
[18:08] <teward> patdk-wk: i think herrkin wants to give the client the box and NOT give the client the key, so they can't access the files on the devices
[18:08] <teward> which makes zero sense
[18:08] <patdk-wk> yes, I do the same
[18:08] <patdk-wk> but then you have to give it the key on each reboot
[18:08] <herrkin> all I want is they can reboot the system but not access the files
[18:09] <teward> herrkin: mutually exclusive options
[18:09] <patdk-wk> won't happen
[18:09] <herrkin> it seems impossible as you say
[18:09] <teward> herrkin: you get one, or the other
[18:09] <patdk-wk> herrkin, even if you used FDE that won't happen
[18:09] <teward> either they can reboot the box and put in the key, or, you give the machine the key each boot.
[18:09] <herrkin> if I enctypt the disk and give them the key its like I wasnt enctypting anything
[18:09] <herrkin> so why bother?
[18:09] <patdk-wk> forget all that, your protecting against the wrong thing
[18:09] <teward> ^
[18:10] <patdk-wk> when using FDE, if the server is on, it's as good as vaunerable
[18:10] <patdk-wk> only when it's powered off is it safe
[18:10] <patdk-wk> so yes, they can't remove the drive and reboot
[18:10] <patdk-wk> but they can attack it while it's turned on plunty
[18:10] <herrkin> wow thats frustrating
[18:11] <patdk-wk> if it was simple
[18:11] <patdk-wk> everyone owuld have perfect security
[18:11] <patdk-wk> and there would be no market
[18:11] <herrkin> it seems any system is vulnerable then?
[18:11] <patdk-wk> anything that can be turned on, is
[18:11] <teward> yep
[18:12] <patdk-wk> it's how you want to protect it, and what you want to protect against, that drives up how hard/costly it is to do
[18:12] <patdk-wk> using a tpm module will let you autoreboot
[18:12] <patdk-wk> and will protect against drive removal
[18:12] <patdk-wk> but it won't protect against attacks against that same machine
[18:12] <patdk-wk> or bios issues
[18:12] <herrkin> what is tpm?
[18:13] <teward> https://en.wikipedia.org/wiki/Trusted_Platform_Module I think
[18:13] <herrkin> sorry there are some things I have never used so I get confused
[18:13] <patdk-wk> I use tpm's on many things
[18:13] <herrkin> how would it protect against drive removal?
[18:13] <patdk-wk> some with passwords, others without
[18:13] <patdk-wk> the drive is encrypted
[18:13] <patdk-wk> cannot be decrypted without the tpm
[18:14] <patdk-wk> the tpm cannot be removed from that computer
[18:14] <herrkin> patdk-wk, please tell me the way you protect your work
[18:14] <patdk-wk> I don't attempt to protect against the impossible :)
[18:14] <patdk-wk> I am only required to protect against powered-off states
[18:14] <patdk-wk> not powered-on
[18:14] <patdk-wk> fde works great for that
[18:14] <herrkin> exactly
[18:15] <herrkin> all I want is that they cant remove the drive and access it from another machine thus grabbing the files
[18:15] <patdk-wk> use a tpm then
[18:15] <teward> FDE (Full Disk Encryption), + TPM module
[18:15] <patdk-wk> the FDE passcode will be generated and stored in the tpm only
[18:15] <herrkin> and also prevent the grub from changing pass
[18:16] <herrkin> thats another thing I havent been able to do
[18:16] <patdk-wk> heh?
[18:16] <patdk-wk> what does grub have to do with FDE?
[18:16] <herrkin> there was a time when I lost my pass
[18:16] <herrkin> I remember I read on a page that I just go on grub and type some commands
[18:16] <herrkin> I override the root pass
[18:17] <herrkin> I could log to the system
[18:17] <herrkin> that is something I want to prevent too.
[18:17] <patdk-wk> yes, all that requires having the disk
[18:17] <patdk-wk> and we just told you to use fde
[18:17] <herrkin> ok
[18:17] <patdk-wk> if yo uwant to protect against that
[18:17] <herrkin> I will look for that.
[18:17] <patdk-wk> if you want to protect against something when it's *powered-on* and working, that is totally different
[18:17] <teward> i feel like we're going in circles, so I'm going to go get lunch.

[18:18] <patdk-wk> but to protect against powered off, fde+tpm will do the job for you
[18:18] <herrkin> lol.
[18:18] <herrkin> sorry teward
[18:18] <herrkin> good
[18:18] <herrkin> another thing the key sharing.
[18:18] <patdk-wk> key sharing? no idea what that is
[18:18] <herrkin> how you prevent them to grab the files if they have the key?
[18:18] <herrkin> the encryption key
[18:18] <patdk-wk> how would they get the encryption key?
[18:19] <herrkin> you said you would give it to them so they can reboot
[18:19] <patdk-wk> on my systems yes
[18:19] <herrkin> hm..
[18:19] <patdk-wk> but we aren't discussing my system
[18:19] <patdk-wk> but what you need
[18:20] <patdk-wk> for you, a tpm would be perfect
[18:20] <patdk-wk> for me, sometimes tpm
[18:20] <patdk-wk> but I also want to protect against someone stealing my server
[18:20] <herrkin> ok, that way you are telling me it allows to reboot without asking for an encryption key?
[18:20] <patdk-wk> and so my tpm would need a password
[18:20] <patdk-wk> the encryption key is stored in the tpm
[18:20] <herrkin> oh.. great
[18:20] <patdk-wk> if you password the tpm is optional
[18:21] <patdk-wk> if you don't put a password on the tpm
[18:21] <patdk-wk> that drive is now locked to that computer
[18:21] <herrkin> ok, so much to learn
[18:21] <patdk-wk> without that *computer* the drive must be wiped
[18:21] <patdk-wk> tpm's are bound to the system they are put into
[18:21] <patdk-wk> even doing a bios update on it, will cause the tpm to break
[18:22] <herrkin> and changing its hardware does it too?
[18:22] <patdk-wk> motherboard, yes
[18:22] <patdk-wk> other stuff, likely not
[18:22] <herrkin> for example more ram, another nic, whatever
[18:23] <TJ-> Guys, I think the background to this says everything, since it's a continuation of a long-running saga. If I recall correct, the server is owned by, and on the premises of, a customer of herrkin, who installs his proprietary code on said server. herrkin is trying to prevent the customer having any access to the source-code of his application.
[18:23] <herrkin> ok then I will research about tpm fde
[18:24] <TJ-> Last time I recall they wanted log-on/root access to 'change the IP' and we ended up recommending simply putting a cheal router 'in front' of the server so the customer changed the router config, not the server.
[18:24] <herrkin> yes :D
[18:24] <herrkin> that was just an idea, I like that.
[18:25] <TJ-> And before that, when this situation of protecting the code came up, I said it was a pointless endeavour
[18:25] <TJ-> If you don't have trust in a customer don't do business with them
[18:28] <herrkin> yeah its just inevitable. I want to protect from anything. sorry if I am bothering you, I am learning a lot from you.
[18:28] <TJ-> herrkin: the only solution is to host the service off-site where you have full physical control
[18:29] <TJ-> herrkin: you could always do that, and then set up a VPN from your server to the customer's premises, or to the customer server, which simply acts as a proxy - therefore it would not store your code on it
[18:31] <herrkin> that wouldn't be efficient because the internet in my country is a crap. instead some of my clients have several servers to handle local data and then replicate
[18:32] <herrkin> the thing is a matter of availability, internet is either not so good or not available
[18:32] <patdk-wk> ya, I dunno the whole story, just what I ran into the middle of :)
[18:33] <herrkin> so they need to have the server in premises
[18:33] <patdk-wk> but yes, it all come down to what you are protecting against
[18:33] <patdk-wk> but pulling a harddrive out of the box, fde is required, and tpm to do the fde is likely needed in this case
[18:33] <patdk-wk> since you don't want to manage keys
[18:33] <patdk-wk> but to do other kids, it's different
[18:34] <herrkin> yes its seems like the solution.
[18:35] <patdk-wk> kinds
[18:35] <herrkin> oh its a hardware ? lol.
[18:35] <patdk-wk> yes
[18:36] <herrkin> no way, I think I just leave that unprotected, I can't do much about it
[18:36] <herrkin> thanks for clearing it out. sorry for the time wasted. I appreciate it.
[18:36] <patdk-wk> most motherboards support tpm modules
[18:36] <patdk-wk> it's just a chip you plug into the motherboard
[18:36] <patdk-wk> :)
[18:40] <TJ-> herrkin: clearly display your copyright messages in every file, and in the log-on MOTD; that's about the best you can do
[18:41] <herrkin> yes. thanks.
[18:41] <herrkin> honestly I wanted to marry them to our support, if they can gain access the code they can edit it and do what they need.
[18:43] <herrkin> off course we could detect if the code has been changed, and one thing to do is not leave the ssh key of our repository, it could be brutal.
[18:43] <herrkin> its not that I dont trust them, I am just being paranoic lol. anything can hapen.
[18:59] <TJ-> herrkin: you could embed methods that check known cryptographic hashes of the file(s) with live-generated hashes, and cause your service to stop/warn/error if changes are detected
[19:01] <herrkin> hm.. like md5 hash of the files? check sums?
[19:10] <bindi> ubuntu server 14.04, will it run irssi in a screen with 3GB disk space? :P
[19:10] <bindi> i mean sure the wiki page says minimum is 1
[19:11] <bearface_> bindi: it should be able to
[19:34] <herrkin> TJ-, the thing that worries me the most now that its like that is that they could easily see the db password and screw or edit the data at will living us in a horrible possition. I mean some black hat technisian with a will to distroy it, literally could do it.
[19:59] <TJ-> herrkin: if it is their data why worry? if they change it that's their issue, totally outside your responsibility.
[20:57] <herrkin> they could think its a malfunction of the system. (lack of security) they could blame us for that. TJ-
[21:12] <TJ-> herrkin: negoitate sensible terms, in writing, so both parties understand what is an isn't your responsibilty, and what is theres (like not interfering with the code or database, keeping a written log of all access they make to the server, etc.)
[21:12] <herrkin> ok thanks
[21:14] <TJ-> herrkin: ensure the server keeps good logs of everything, and have it forward them to you on a schedule using cron, maybe
[21:16] <herrkin> good what type of logs, access logs?
[21:22] <TJ-> Yes, and database access, any kind of program-controlled access to your running code
[21:31] <herrkin> got it, thanks