chat.freenode.net #tryton log beginning Mon Dec 17 00:00:01 CET 2012 | ||
2012-12-17 08:40 <Demosthenex> so i'm shopping for business software... nothing complex. i run a services business of low volume. bill hours currently in freshbooks, and do my own billable travel expenses in ledger (the most complicated part). i'm seeking an accounting platform to tie those elements in together, and maybe replace the other tools. would tryton be suitable, or is it just a base? | ||
2012-12-17 09:34 <iamnoob> hi good day | ||
2012-12-17 09:35 <iamnoob> can anyone please help me on the "incompatible version of the server" problem? whats the proper version do i need to use? | ||
2012-12-17 09:38 <corro> iamnoob: just use versions from the same release (2.2.x, 2.4.x or 2.6.x) for both server and client | ||
2012-12-17 10:01 <iamnoob> hi corro.. i downloaded ver 2.0.1 server and client and installed it. but when i check the version it saids tryton = 2.6.0 , trytond = 2.0.1 im using ubuntu 11.10 btw. any idea why this is happening? thanks | ||
2012-12-17 10:04 <corro> iamnoob: how did you install the packages? Via apt or pip/easy_install? | ||
2012-12-17 10:09 <iamnoob> i downloaded the .deb files on tryton.org download page.. i got the server now to version 2.2.3. im trying to make the client to 2.2.3 too but got an error.. unistalling then installing it again now.. | ||
2012-12-17 10:12 <iamnoob> after unistalling/installng the client and installing th client 2.2.3 (to match up with my 2.2.3 server) when i try to run it. nothing happens =( | ||
2012-12-17 10:13 <corro> iamnoob: tryton.org does not provide .deb packages, only a link to the official ubuntu repository. Anyway, try running the client in the console and look for an error message. | ||
2012-12-17 10:14 <iamnoob> corro: i got the following error when running tryton on a terminal | ||
2012-12-17 10:14 <iamnoob> from tryton.config import CONFIG | ||
2012-12-17 10:14 <iamnoob> File "/home/haw/.local/lib/python2.7/site-packages/tryton/config.py", line 191, in <module> | ||
2012-12-17 10:14 <iamnoob> os.path.join(PIXMAPS_DIR, 'tryton-icon.png').encode('utf-8')) | ||
2012-12-17 10:14 <iamnoob> glib.GError: Failed to open file '/usr/bin/share/pixmaps/tryton/tryton-icon.png': No such file or directory | ||
2012-12-17 10:21 <corro> iamnoob: looks like you have some artifacts of a previous installation under ~/.local. Try renaming ~/.local/lib/python-2.7/site-packages to something else. | ||
2012-12-17 10:22 <rmu> iamnoob: http://code.google.com/p/tryton/wiki/InstallationOnDebian | ||
2012-12-17 10:23 <rmu> iamnoob: also applies for ubuntu | ||
2012-12-17 10:39 <iamnoob> ok ill try it corro,rmu thanks | ||
2012-12-17 14:00 <rmu> somehow i managed end up with a user with number "10" in login_try column | ||
2012-12-17 14:01 <rmu> in res_users | ||
2012-12-17 14:01 <rmu> --> server sleeps 1024s | ||
2012-12-17 14:03 <rmu> i suggest that in a new design that decouples login_try from res_users this value is limited to some "useful" upper maximum and/or replaced with locking of account if there are too many tries. | ||
2012-12-17 14:09 <cedk> rmu: limitation is already done on number of thread/connection | ||
2012-12-17 14:11 <rmu> cedk: not really if i reconnect again from different machine, and try again after restart of server, on next day, etc.... | ||
2012-12-17 14:11 <cedk> rmu: and what is the problem? | ||
2012-12-17 14:13 <rmu> cedk: it seems this number can become arbitrarily large. sleeping more than 30seconds because of wrong password is not necessary | ||
2012-12-17 14:13 <rmu> and it seems you could possibly DOS the server | ||
2012-12-17 14:15 <rmu> nevermind | ||
2012-12-17 14:22 <cedk> rmu: ha you are talking about the sleep | ||
2012-12-17 14:22 <cedk> rmu: I don't see how it can DDOS the server, sleep cost nothing | ||
2012-12-17 14:22 <cedk> rmu: and it doesn't prevent other connections to work | ||
2012-12-17 14:29 <rmu> cedk: it takes one thread per sleep | ||
2012-12-17 14:30 <rmu> just wanted to try it with proteus and noticed that proteus with trytond doesn't do a login? at least it doesn't check the password | ||
2012-12-17 14:31 <cedk> rmu: yes but the number of thread is limited | ||
2012-12-17 14:31 <cedk> rmu: for proteus no need to login if you use trytond | ||
2012-12-17 14:31 <rmu> cedk: so if the thread-limit is reached, the server is effectively DOSed | ||
2012-12-17 14:32 <cedk> rmu: no, he still serves the existing threads | ||
2012-12-17 14:32 <rmu> i can easily make the "sleeping" thread sleep for days | ||
2012-12-17 14:33 <rmu> i can fill issue if you want | ||
2012-12-17 14:34 <cedk> rmu: and what is the problem? | ||
2012-12-17 14:35 <rmu> the problem is: user tries to login (with wrong password, but doesn't notice), login is unresponsive. user kills client. ad nauseum. | ||
2012-12-17 14:35 <rmu> each try, login_try is incremented, and one server thread sleeps 2^login_try seconds | ||
2012-12-17 14:36 <rmu> problems: the user doesn't get feedback that he entered wrong password, at least not in time (who waits for 15minutes or more for some result that should show in mere seconds) | ||
2012-12-17 14:37 <rmu> and it is possible to DOS the server. even if you say that existing connections continue to work, new ones also should work | ||
2012-12-17 16:00 <cedk> rmu: yes, it could be improved by stopping the thread if the connection is closed by the user | ||
2012-12-17 16:06 <rmu> what use is this sleep anyway | ||
2012-12-17 16:07 <rmu> stopping the thread if the user closes the connection would effectively mean getting rid of the sleep | ||
2012-12-17 16:10 <cedk> rmu: sleep is very important to prevent brute-force attack | ||
2012-12-17 16:12 <rmu> cedk: but it doesn't really prevent brute force attack | ||
2012-12-17 16:12 <rmu> cedk: you can open another connection and try again (modulo maximum thread count) | ||
2012-12-17 16:13 <cedk> rmu: yes so it prevents | ||
2012-12-17 16:13 <rmu> cedk: you prevent legitimate users from logging in/verifying their password if idle too long | ||
2012-12-17 16:14 <cedk> rmu: not if you type your right password | ||
2012-12-17 16:14 <rmu> ok not password verif., this is blocked only when running the production wizard | ||
2012-12-17 16:15 <cedk> rmu: but that's an other issue | ||
2012-12-17 16:15 <rmu> cedk: legitimate users won't wait 2^20 seconds until some "bad login/passwort" dialog pops up, but call support | ||
2012-12-17 16:16 <rmu> cedk: yes thats another issue... but related somehow | ||
2012-12-17 16:19 <cedk> rmu: there is no reason to have to wait so much except if it tries 20 bad password | ||
2012-12-17 16:20 <cedk> rmu: or if someone try to brute-force his password so it is still good to inform the support to find the cracker | ||
2012-12-17 16:21 <rmu> because of missing feedback, seemingly blocking client in case of long sleep, user may think something is strange, kill the client, and try agai | ||
2012-12-17 16:21 <rmu> n | ||
2012-12-17 16:22 <cedk> rmu: missing feedback is the important part of the security | ||
2012-12-17 16:23 <rmu> no, not really, the client could say /something/ | ||
2012-12-17 16:23 <rmu> but as it is, the user doesn't really know if the VPN is having trouble or the login is waiting... | ||
2012-12-17 16:24 <rmu> but, as i said, nevermind, i logged a wishlist-issue; if this login_try gets redesigned, perhaps somebody will have a look at it | ||
2012-12-17 16:26 <rmu> and, btw, deactivating an account after 5/10/whatever missed logins, and telling the user "account disabled", would not be a security problem. | ||
2012-12-17 16:27 <cedk> rmu: it is a security issue for me because it will make so easy to disable any login by some malicious people | ||
2012-12-17 16:28 <rmu> cedk: but malicious people can already deactivate any login, they just have to keep 10 connections open | ||
2012-12-17 16:28 <rmu> or whatever is configured | ||
2012-12-17 16:32 <cedk> rmu: it doesn't because if password is right it returns directly without sleep | ||
2012-12-17 16:37 <rmu> cedk: without having looked at the source, you can't have the sleep block the connection and not need a separate thread at the same time | ||
2012-12-17 16:46 <cedk> rmu: don't understand | ||
2012-12-17 16:46 <yangoon> rmu: +1, security by obscurity is never a good choice | ||
2012-12-17 16:48 <cedk> yangoon: what is obscurity ? | ||
2012-12-17 16:48 <yangoon> cedk: missing feedback as part of security | ||
2012-12-17 16:49 <cedk> yangoon: I don't understand what you mean, it is not usefull to say such mantra that doesn't apply at all to the subject | ||
2012-12-17 16:51 <yangoon> cedk: where do you not understand, that this mantra doesn't apply to the subject? | ||
2012-12-17 16:53 <cedk> yangoon: there is no obscurity | ||
2012-12-17 16:54 <yangoon> not giving feedback lets the user in obscurity | ||
2012-12-17 16:54 <bechamel> yangoon: I think that when cedk said "it is a security issue for me because it will make so easy to disable any login by some malicious people" he wasn't talking about the user feedback, but about the account desactivation (am I right cedk ?) | ||
2012-12-17 16:56 <yangoon> bechamel: I am just referring to (16:22:35) cedk: rmu: missing feedback is the important part of the security as answer to (16:21:54) rmu: because of missing feedback, seemingly blocking client in case of long sleep, user may think something is strange, kill the client, and try again | ||
2012-12-17 16:56 <cedk> bechamel: yes | ||
2012-12-17 16:56 <cedk> yangoon: ok it is not missing feedback but delay feedback for exponential time | ||
2012-12-17 16:58 <yangoon> cedk: which results indeed in being missing feedback for a long time in certain circumstances | ||
2012-12-17 16:59 <rmu> in ideal software, behaviour like this would be configureable, because requirements and habits regarding passwords and login depend on the organization | ||
2012-12-17 17:00 <rmu> i'm just writing a test to DOS my own server ;) | ||
2012-12-17 17:01 <bechamel> IMO DOS is really hard to avoid, even without login timeout, example: http://en.wikipedia.org/wiki/Denial-of-service_attack#SYN_flood | ||
2012-12-17 17:02 <cedk> rmu: I never said that trytond could not be DOS, indeed I think there are no software fully secure on this topic | ||
2012-12-17 17:02 <cedk> rmu: all you can do is trying to stay alive | ||
2012-12-17 17:03 <rmu> i know | ||
2012-12-17 17:08 <cedk> rmu: also the firewall should take a good part in the protection | ||
2012-12-17 17:09 <rmu> all i'm arguing for is that endlessly doubling the time in sleep is nonsense... there should be an upper limit of about 15 to 30 seconds, like e.g. in the windows ctl-alt-del login dialog | ||
2012-12-17 17:10 <rmu> that is enough to prevent brute forcing the password | ||
2012-12-17 17:11 <rmu> and it would be easier on the resources, as this sleep-call binds one database connection | ||
2012-12-17 17:11 <cedk> rmu: I don't agree with a limit you just delay the brute-force | ||
2012-12-17 17:13 <rmu> i didn't test what happens when the client closes the connection and the server-thread is sleeping | ||
2012-12-17 17:13 <rmu> if this does abort the sleep, then brute-forcing is possible at near "full speed" | ||
2012-12-17 17:13 <cedk> rmu: agree that we could improve to close the DB connection before sleeping | ||
2012-12-17 17:14 <rmu> cedk: but then nothing prevents the brute-forcer to open as much connections as he likes | ||
2012-12-17 17:14 <cedk> rmu: don't understand | ||
2012-12-17 17:14 <cedk> rmu: yes of course but each one will sleep more and more | ||
2012-12-17 17:14 <rmu> wait for 1s, see if positive answer arrives, if not, try next password | ||
2012-12-17 17:15 <rmu> i think the thing that probably limits first is the number of db-connections | ||
2012-12-17 17:17 <rmu> the client can assume that the server answers with "login ok" if he tries the correct password... if this answer doesn't arrive within (short) timeout, try again | ||
2012-12-17 17:18 <rmu> so if you keep db-connection while sleeping, this amounts to complete DOS in no time (after about 100 tries 64 threads will sleep for days each) | ||
2012-12-17 17:19 <cedk> rmu: yes but there is nothing to do against that, at least not at trytond level | ||
2012-12-17 17:19 <rmu> if you don't keep db-connection while sleeping, the client can try as much parallel logins as threads are available (doesn't seem to be limited in python, so some os-limit will define this) | ||
2012-12-17 17:20 <rmu> cedk: i agree there is not that much you can do against malicious users DOSsing the server, if they really want | ||
2012-12-17 17:21 <rmu> cedk: but usually, you don't have malicious users on the network where tryton is accessible (hopefully), and user-error is your main problem | ||
2012-12-17 17:22 <cedk> rmu: before we got a thread limit that was removed because SocketServer.ThreadingMixIn did not have such option but it could be re-added | ||
2012-12-17 17:22 <rmu> and a typical tryton users are half-computer-illiterate folks that CAPS-LOCK without noticing, entering the password a few times, and then think the computer is dead | ||
2012-12-17 17:23 <cedk> rmu: we can not do anything against such people | ||
2012-12-17 17:23 <rmu> cedk: you shouldn't do anything against your users ;-) you should make their life easier | ||
2012-12-17 17:24 <cedk> rmu: life easier == no password | ||
2012-12-17 17:25 <rmu> that would be "too big" easy | ||
2012-12-17 17:25 <Pilou> life easier == SSO ;) | ||
2012-12-17 17:26 <rmu> what would you do if SSHing to a machine doesn't react for 1000s of seconds? assume that someone tried to brute force the password? | ||
2012-12-17 17:26 <rmu> i would assume the network had a problem ;) | ||
2012-12-17 17:27 <cedk> rmu: after I type the password, no I will not assume that | ||
2012-12-17 17:28 <rmu> but typical MTU-related problems especially prevalent with certain kinds of VPN manifest just that way | ||
2012-12-17 17:30 <cedk> rmu: the first time you use it but not on daily usage | ||
2012-12-17 17:37 <Demosthenex> so i'm shopping for business software... nothing complex. i run a services business of low volume. bill hours currently in freshbooks, and do my own billable travel expenses in ledger (the most complicated part). i'm seeking an accounting platform to tie those elements in together, and maybe replace the other tools. would tryton be suitable, or is it just a base? | ||
2012-12-17 17:39 <cedk> Demosthenex: difficult to say, it could but you should test it | ||
2012-12-17 17:42 <rmu> cedk: I would not bet on it - in reality, these things are in permanent flux, expecially in large organizations, and only ever really tested/deployed for windows clients. | ||
2012-12-17 17:44 <Demosthenex> cedk: i figure the expenses piece i'm going to have to reimplement... | ||
2012-12-17 17:46 <cedk> Demosthenex: you said that you do it directly in ledger? | ||
2012-12-17 17:50 <Demosthenex> cedk: currently, i'm one of the more prolific ledger (cli, text files) users | ||
2012-12-17 17:50 <Demosthenex> a combination of frequent splits, heavy metadata, scanned images, etc. | ||
2012-12-17 17:51 <Demosthenex> and all custom logic on top in shell scripts and perl (pdf generation) | ||
2012-12-17 17:52 <Demosthenex> i'm trialing Xero and Kashoo, because i need something with business accounting structures already built in to reconcile my bank accounts against | ||
2012-12-17 17:54 <cedk> Demosthenex: expense are like supplier invoice | ||
2012-12-17 17:55 <Demosthenex> travel expenses, billed at actual to client | ||
2012-12-17 17:55 <Demosthenex> lots of little items, subject to rules by client | ||
2012-12-17 17:56 <Demosthenex> let's not forget importing from csv/ofxc | ||
2012-12-17 17:57 <Demosthenex> i'm outgrowing text, and moving to a DB my choices are: a scratch reimplementation or use an existing product to build on | ||
2012-12-17 17:57 <cedk> Demosthenex: with Tryton you will be able to customize the generic workflow to yours | ||
2012-12-17 18:00 <Demosthenex> cedk: i'm certain, in fact, i rather like what i've read so far for building the expenses workflow | ||
2012-12-17 18:00 <Demosthenex> what i'm concerned about is whether the accounting backend has what's needed. | ||
2012-12-17 18:03 <cedk> Demosthenex: what do you need? | ||
2012-12-17 18:08 <Demosthenex> i guess my question is, is tryton more of a toolkit or does it have working components already? | ||
2012-12-17 18:08 <cedk> Demosthenex: it is both | ||
2012-12-17 18:08 <cedk> Demosthenex: it is a toolkit because we try to make it flexible and customizable as much as possible | ||
2012-12-17 18:09 <cedk> Demosthenex: but it is also a working components for basis | ||
2012-12-17 18:11 <Demosthenex> interesting | ||
2012-12-17 18:12 <cedk> Demosthenex: indeed it was the subject of a talk at the TUL, that's Tryton is somehow both and that is difficult to communicate on it | ||
2012-12-17 18:12 <Demosthenex> know anyone doind postgres binary blobs for scanned images with tryton? | ||
2012-12-17 18:14 <cedk> Demosthenex: I will suggest to use the same storage as we do for attachment | ||
2012-12-17 18:14 <cedk> Demosthenex: store the data on the filesystem | ||
2012-12-17 18:15 <cedk> Demosthenex: even if postgresql manage blobs quite well, it is still better to have it on the filesystem | ||
2012-12-17 18:15 <cedk> Demosthenex: as it is data that don't change, you can backup only the diff | ||
2012-12-17 18:15 <cedk> Demosthenex: but in DB, you have to dump everything each time | ||
2012-12-17 18:15 <Demosthenex> why? i've read some folks argue this back and forth in internet threads... my only argument is sync issues | ||
2012-12-17 18:15 <Demosthenex> we're talking static scanned images. | ||
2012-12-17 18:16 <cedk> Demosthenex: we store attachment based on their hash in 2 levels directories | ||
2012-12-17 18:16 <Demosthenex> i've seen that before, that's not too bad. | ||
2012-12-17 18:17 <cedk> Demosthenex: and we never remove files | ||
2012-12-17 18:17 <cedk> Demosthenex: just delete reference in the DB | ||
2012-12-17 18:17 <cedk> Demosthenex: the main advandage for me is the backup system | ||
2012-12-17 18:18 <Demosthenex> diff on FS, vs dumping blobs. | ||
2012-12-17 18:18 <Demosthenex> i can see that | ||
2012-12-17 18:18 <Demosthenex> so i hear on the site there's companies and indivduals providing commercial support... | ||
2012-12-17 18:18 <Demosthenex> perhaps i should check them out | ||
2012-12-17 18:19 <cedk> Demosthenex: I'm from B2CK | ||
2012-12-17 18:25 <Demosthenex> ah! | ||
2012-12-17 18:26 <Demosthenex> well i do run a successful business, and i'm not shy about paying reasonable amounts to get things done. | ||
2012-12-17 18:26 <Demosthenex> i'm just sick of accounting ;] | ||
2012-12-17 19:02 <Demosthenex> cedk: so how about quoting me on customizing tryton to a use case? | ||
2012-12-17 19:08 <cedk> Demosthenex: B2CK provides such services | ||
2012-12-17 19:10 <Demosthenex> cedk: i' | ||
2012-12-17 19:10 <Demosthenex> cedk: i'm all ears | ||
2012-12-17 19:10 <Demosthenex> i can describe my workflow pretty easily | ||
2012-12-17 19:10 <Demosthenex> at this point i write it myself or pay someone to customize an existing system. | ||
2012-12-17 19:11 <cedk> Demosthenex: send us your use case | ||
2012-12-17 19:11 <Demosthenex> cedk: have an email? | ||
2012-12-17 19:11 <Demosthenex> or contact data | ||
2012-12-17 19:11 <cedk> Demosthenex: http://www.b2ck.com/tryton_services.html | ||
2012-12-17 19:14 <cedk> Demosthenex: I will also suggest you to try the demo server to have some idea about how Tryton works etc. | ||
2012-12-17 19:16 <Demosthenex> *nod* i'm having a peek and writing up a use case ;] | ||
2012-12-17 19:16 <Demosthenex> i'd rather put my money toward OSS solutions... | ||
2012-12-17 19:16 <Demosthenex> my business isn't unique | ||
2012-12-17 19:32 <Pilou> Demosthenex: Would you want distribute these custom modules ? | ||
2012-12-17 19:35 <Demosthenex> Pilou: they can remain oss | ||
2012-12-17 19:51 <Demosthenex> cedk: sent one off | ||
2012-12-17 20:04 -!- Demosthenex(~Demosthen@206.180.155.43.adsl.hal-pc.org) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!